*** dafox has joined #maemo | 00:14 | |
*** florian has quit IRC | 02:46 | |
*** spiiroin_ has joined #maemo | 02:50 | |
*** spiiroin has quit IRC | 02:53 | |
*** hurrian has joined #maemo | 03:21 | |
*** hurrian_ has quit IRC | 03:21 | |
*** infobot has quit IRC | 03:23 | |
*** infobot has joined #maemo | 03:24 | |
*** LouisA has joined #maemo | 03:35 | |
LouisA | hey guys | 03:35 |
---|---|---|
*** xy2_ has quit IRC | 03:48 | |
*** dafox has quit IRC | 04:03 | |
*** cyphase has quit IRC | 04:25 | |
*** cyphase has joined #maemo | 04:30 | |
*** hurrian has quit IRC | 04:57 | |
*** hurrian has joined #maemo | 04:58 | |
*** LouisA has quit IRC | 05:22 | |
*** luke-jr has quit IRC | 06:19 | |
*** luke-jr has joined #maemo | 06:27 | |
*** vahe has joined #maemo | 06:38 | |
*** pagurus` has joined #maemo | 06:45 | |
*** pagurus has quit IRC | 06:47 | |
*** pagurus` has quit IRC | 06:47 | |
*** pagurus has joined #maemo | 06:47 | |
*** Zungo has quit IRC | 07:28 | |
*** DocScrutinizer05 has quit IRC | 07:31 | |
*** DocScrutinizer05 has joined #maemo | 07:31 | |
*** sunshavi has quit IRC | 08:11 | |
*** sledges has quit IRC | 10:34 | |
*** ginggs has quit IRC | 10:50 | |
*** ginggs has joined #maemo | 10:51 | |
*** HRH_H_Crab has quit IRC | 10:52 | |
*** HRH_H_Crab has joined #maemo | 10:54 | |
*** xorly has joined #maemo | 10:57 | |
*** Ex-Opesa has quit IRC | 11:13 | |
*** xorly has quit IRC | 11:30 | |
*** xorly has joined #maemo | 11:31 | |
*** xorly has quit IRC | 11:51 | |
*** xorly has joined #maemo | 11:52 | |
*** crazyguy` has joined #maemo | 12:22 | |
*** florian has joined #maemo | 12:28 | |
*** LouisA has joined #maemo | 13:12 | |
*** shentey has joined #maemo | 13:44 | |
*** Pali has joined #maemo | 13:44 | |
*** shentey has quit IRC | 13:51 | |
*** shentey has joined #maemo | 13:51 | |
*** Pali has quit IRC | 14:16 | |
*** xy2_ has joined #maemo | 14:42 | |
*** hurrian has quit IRC | 14:51 | |
*** L29Ah has joined #maemo | 14:57 | |
*** L29Ah has left #maemo | 15:13 | |
*** LouisA has quit IRC | 15:16 | |
*** hurrian has joined #maemo | 15:21 | |
*** herekun has joined #maemo | 15:35 | |
*** shentey_ has joined #maemo | 15:49 | |
*** shentey has quit IRC | 15:52 | |
*** xy2_ has quit IRC | 15:56 | |
*** xy2_ has joined #maemo | 15:57 | |
*** xy2_ has quit IRC | 16:10 | |
*** xy2_ has joined #maemo | 16:12 | |
*** dafox has joined #maemo | 16:18 | |
*** mavhc has quit IRC | 17:16 | |
*** mavhc has joined #maemo | 17:19 | |
*** Cor-Ai has quit IRC | 17:20 | |
*** Cor-Ai has joined #maemo | 17:24 | |
*** SmilyOrg has joined #maemo | 18:05 | |
*** Smily has quit IRC | 18:05 | |
*** auenfx4 has joined #maemo | 18:16 | |
*** auenf has quit IRC | 18:16 | |
*** L29Ah has joined #maemo | 18:18 | |
*** L29Ah has left #maemo | 18:40 | |
*** L29Ah has joined #maemo | 18:55 | |
*** shentey_ has quit IRC | 19:02 | |
*** auenfx4 has quit IRC | 19:10 | |
*** auenf has joined #maemo | 19:14 | |
*** xy2_ has quit IRC | 19:20 | |
*** xy2_ has joined #maemo | 19:21 | |
*** L29Ah has left #maemo | 19:25 | |
*** L29Ah has joined #maemo | 19:25 | |
*** msava has joined #maemo | 19:47 | |
*** msava has quit IRC | 19:48 | |
*** msava has joined #maemo | 19:48 | |
*** msava has quit IRC | 19:50 | |
*** msava has joined #maemo | 19:51 | |
*** msava has quit IRC | 19:52 | |
*** msava has joined #maemo | 20:03 | |
*** Pali has joined #maemo | 20:03 | |
*** msava has quit IRC | 20:03 | |
*** msava has joined #maemo | 20:04 | |
*** msava has quit IRC | 20:04 | |
*** mp107 has joined #maemo | 20:24 | |
*** vahe has quit IRC | 20:27 | |
*** platicus has quit IRC | 20:58 | |
*** tanty has quit IRC | 20:58 | |
freemangordon | Pali: ping | 20:59 |
*** platicus has joined #maemo | 20:59 | |
*** tanty has joined #maemo | 20:59 | |
freemangordon | anyway, it is not a question only for Pali, so... | 21:00 |
freemangordon | Wizzup: parazyd: while implementing maemo gtk on top of upstream, I am facing a hard to be solved problem how to access various widgets private structure members | 21:01 |
freemangordon | I can think of 2 options, both of them i don;t really like: | 21:01 |
freemangordon | 1. redefine private structure in my code, call g_type_instance_get_private and call it a day. | 21:03 |
freemangordon | 2. reimplement the whole class instead of just subclassing | 21:03 |
freemangordon | 1. is really, really ugly, but needs less coding | 21:04 |
freemangordon | 2, is not *that* ugly, but I'll have to LD_PRELOAD hildon-gtk and hack in the gtk_whatever_widget functions, which may conflict with GTK3 programs. also, I am not sure how will that work in case of "inter-gtk" calls | 21:06 |
freemangordon | so, do you have any other idea on how to achieve that? | 21:07 |
freemangordon | bencoh: KotCzarny: the same question to you, and all other that can help | 21:07 |
freemangordon | *all others | 21:07 |
KotCzarny | arent private members meant to be private? | 21:07 |
freemangordon | yes, but I am trying to act like a part of gtk itself | 21:08 |
KotCzarny | ie. either find interface/func to access them or it might fall apart/be incompatible | 21:08 |
*** tanty has quit IRC | 21:08 | |
*** platicus has quit IRC | 21:08 | |
freemangordon | yes, I know | 21:08 |
freemangordon | thus "really, really ugly" | 21:08 |
KotCzarny | gtk has a concept of custom widgets? | 21:08 |
freemangordon | I am trying to implement hildon gtk, without patching gtk code :) | 21:09 |
*** platicus has joined #maemo | 21:09 | |
*** tanty has joined #maemo | 21:09 | |
KotCzarny | and you want to overload them in existing apps or just add hildon functionality? | 21:09 |
freemangordon | both | 21:10 |
KotCzarny | hrm | 21:10 |
freemangordon | as adding hildon functionality requires accessing gtk internals | 21:10 |
freemangordon | KotCzarny: see https://github.com/community-ssu/gtk/blob/master/gtk/gtkiconview.c#L1565 | 21:11 |
freemangordon | for example | 21:11 |
KotCzarny | how about writing gtk-hildon port and provide it as an alternative (while being a requirement for hildon enabled apps/) | 21:11 |
bencoh | freemangordon: how does it work thus far then? | 21:11 |
freemangordon | bencoh: where? | 21:11 |
bencoh | and by "upstream" do you mean gtk2 or gtk3 (or doesn't matter)? | 21:11 |
freemangordon | gtk2 | 21:11 |
KotCzarny | in a way jpegturbo 'overloads' libjpeg | 21:11 |
bencoh | freemangordon: on current maemo/gtk2 | 21:11 |
freemangordon | bencoh: code is heavily patched | 21:12 |
KotCzarny | bencoh: on maemo nokia just forked gtk | 21:12 |
freemangordon | KotCzarny: I don't want to fork gtk | 21:12 |
bencoh | freemangordon: gtk on maemo is heavily patched? | 21:12 |
KotCzarny | bencoh: yup | 21:12 |
freemangordon | KotCzarny: re "in a way jpegturbo 'overloads' libjpeg" | 21:13 |
bencoh | I see :/ | 21:13 |
freemangordon | bencoh: just look at GtkIconView code ^^^ | 21:13 |
KotCzarny | fmg, why not? gtk2 wouldnt receive updates afair | 21:13 |
bencoh | freemangordon: aww.... that's not pretty :/ | 21:14 |
KotCzarny | and it would allow you to do things more elegant | 21:14 |
freemangordon | KotCzarny: because, this is lots of work, I'd rather avoid if possible | 21:14 |
KotCzarny | fmg, but you are doing it anyway, no? | 21:14 |
freemangordon | KotCzarny: no | 21:14 |
KotCzarny | i dont understand why do you need private members then and the 'implement hildon functionality' | 21:15 |
*** mp107 has quit IRC | 21:15 | |
freemangordon | or rather - I am doing maemo part only, and if I make it that way, it won;t depend on gtk2 version | 21:15 |
freemangordon | KotCzarny: look at the code ^^^ | 21:15 |
KotCzarny | cant at the moment, console only | 21:15 |
KotCzarny | without mouse | 21:15 |
bencoh | ah :] | 21:16 |
bencoh | copypaste in screen! :D | 21:16 |
KotCzarny | :) | 21:16 |
*** florian has quit IRC | 21:16 | |
freemangordon | will explain - for example GtkIconView has a list of "items" which are in priv struc only, without accessor functions | 21:16 |
freemangordon | hildon gtk draws a tick mark on every selected item | 21:17 |
KotCzarny | hmm, afair you can get access to items in tree/list store | 21:17 |
freemangordon | KotCzarny: how? | 21:17 |
freemangordon | you get some cryptic GtkTreePath or somesuch | 21:17 |
KotCzarny | by accessing it's tree/list store? | 21:17 |
KotCzarny | yeah, its hell to understand, but you can | 21:18 |
freemangordon | there is no way to access it, at least I was unable to find one for the last 3 days | 21:18 |
KotCzarny | check oscp-remote-gtk | 21:18 |
KotCzarny | i have some helper funcs there | 21:18 |
KotCzarny | not the best code in the world but.. | 21:18 |
KotCzarny | let me check the link for you | 21:18 |
freemangordon | where is the code, on github? | 21:19 |
Enrico_Menotti | Hello. I have Devuan booting on the n900. The system image is one I just debootstrapped on Devuan rc which I installed yesterday on my old laptop. But I have problems with the kernel. Someone here (I don't remember who exactly was, if freemangordon or parazyd ) had given me another kernel image. If I use that one, Devuan boots. However, with a kernel I built a few days ago, and also with one built right now, Devuan | 21:19 |
Enrico_Menotti | does not boot (but Debian does). The kernel boots, but does not find selinux; it stays there for a while and then the n900 reboots. If I give init=/bin/sh I get a shell but it's unstable - after a few seconds the n900 reboots. | 21:19 |
KotCzarny | 31.135.195.151:20280/arch/oscp/ | 21:19 |
KotCzarny | sorry, typed that manually | 21:19 |
KotCzarny | it's a source package prepared for arch | 21:20 |
freemangordon | KotCzarny: thanks, going to dig in it | 21:20 |
KotCzarny | oscp-remote-gtk is in libs/_tools/ | 21:20 |
KotCzarny | it's hackish, but works for me | 21:20 |
freemangordon | Enrico_Menotti: sorry, don;t have time now | 21:20 |
bencoh | is wdog enabled at boot? | 21:21 |
Enrico_Menotti | freemangordon No problem. | 21:21 |
KotCzarny | accessing items in both, via iterators and via element reference | 21:21 |
bencoh | (that'd be strange, but ... who knows) | 21:21 |
Enrico_Menotti | bencoh Is there a parameter to enable the watchdog manually? | 21:22 |
freemangordon | KotCzarny: any hint where to look at? as it is lots of code there | 21:22 |
KotCzarny | you probably want to look at oscp-remote-gtk.c func tv_show() | 21:22 |
KotCzarny | and tv_click() | 21:23 |
*** eMHa_ has quit IRC | 21:24 | |
freemangordon | KotCzarny: there is no access to the underlying items, just to the path | 21:25 |
freemangordon | and I didn;t find a way to get dimensions and position of cells in GtkIconView | 21:25 |
freemangordon | and I need those to be able to draw a tick GdkPixbuf | 21:26 |
KotCzarny | why not defining your own widget then? | 21:28 |
freemangordon | KotCzarny: because all maemo applications will have to be ported to use it :) | 21:28 |
KotCzarny | see? fork it | 21:28 |
KotCzarny | :) | 21:29 |
freemangordon | hehe | 21:29 |
freemangordon | I'd rather avoid that if possible | 21:29 |
*** eMHa_ has joined #maemo | 21:30 | |
*** florian has joined #maemo | 21:30 | |
KotCzarny | maybe just replace the icon with tick drawn over it? | 21:31 |
freemangordon | KotCzarny: I cannot get the coordinates of the bounding box of the cell to draw into | 21:32 |
freemangordon | otherwise there is no problem to draw one more icon | 21:32 |
KotCzarny | not one more icon, replace the image | 21:32 |
freemangordon | I cannot do that, see http://talk.maemo.org/showpost.php?p=1527039&postcount=168 | 21:33 |
KotCzarny | will check links tomorrow | 21:33 |
freemangordon | "Activate views" is GtkIconView | 21:34 |
bencoh | Enrico_Menotti: no idea actually, that was just an idea | 21:36 |
Enrico_Menotti | bencoh Actually I think that be the problem. But I don't know why. | 21:36 |
parazyd | Enrico_Menotti: you have to load the watchdog modules on boot, or include them in the kernel | 21:39 |
bencoh | ah :) | 21:39 |
parazyd | i don't remember the names, but grep the kernel config for WATCHDOG | 21:39 |
Enrico_Menotti | parazyd So your kernel has the modules included? | 21:40 |
Enrico_Menotti | Also, why with Debian no problem? | 21:40 |
parazyd | yes, the config is here: https://github.com/dyne/arm-sdk/raw/next/boards/kernel-configs/n900.config | 21:41 |
parazyd | i don't know, i never tried debian | 21:42 |
* DocScrutinizer05 wonders if ANYBODY _ever_ will tackle the relatively (in relation to the above) simple task of just building a maemo5 armel image based on debian/devuan from scratch | 21:42 | |
DocScrutinizer05 | without massive porting to new kernels, new libs, new arch | 21:42 |
parazyd | freemangordon: you cannot get the coordinates of the tick box or the parent? | 21:44 |
freemangordon | parazyd: of the tick box | 21:47 |
freemangordon | parazyd: or to make it more clear - I have to draw tick mark in every selected cell | 21:48 |
parazyd | ah, so you don't know the cell sizes | 21:48 |
freemangordon | mhm | 21:48 |
freemangordon | and positions | 21:48 |
parazyd | no, i thought just spawning the tick box on the opposite of 0,0 | 21:49 |
parazyd | nevermind then :D | 21:49 |
freemangordon | maybe I can calculate those, but ... | 21:49 |
freemangordon | hmm, maybe this is the correct way to do it | 21:49 |
DocScrutinizer05 | I'm afraid this whole porting thing leads nowhere near anything that would be capable of running apps from maemo-extras (unless somebody would recompile them, which obviously is a mad idea to do) | 21:52 |
freemangordon | DocScrutinizer05: actually those should run without recompiling, at least on x86 | 21:53 |
freemangordon | and on armel as well | 21:54 |
KotCzarny | fork the lib, told'ya | 21:54 |
parazyd | aren't the libs they are linked to much older than current? | 21:55 |
KotCzarny | for gtk2 you are quite safe | 21:55 |
freemangordon | parazyd: so? | 21:55 |
freemangordon | KotCzarny: and what about gtk3? | 21:55 |
parazyd | freemangordon: maybe stuff is gone | 21:55 |
KotCzarny | for gtk3 you have to rewrite apps anyway | 21:55 |
KotCzarny | not even recompile would help | 21:55 |
freemangordon | if we talk hildon stuff, what is there is decided by us | 21:56 |
freemangordon | but yeah, there might be removeed function | 21:56 |
freemangordon | *removed functions | 21:56 |
parazyd | yeah i think DocScrutinizer05 is talking about _all_ the software from the repos... anyway. /end bikeshedding | 21:57 |
freemangordon | parazyd: what about having forked gtk2 in devuan-maemo repo? what is the policy? | 21:57 |
parazyd | freemangordon: you're free to do so as long as you keep backwards compat | 21:57 |
parazyd | (because of everything else using gtk2) | 21:57 |
freemangordon | define backwards please | 21:57 |
KotCzarny | plain gtk2 apps | 21:57 |
freemangordon | as it will change the way gtk apps look | 21:57 |
freemangordon | do we talk ABI only here? | 21:58 |
parazyd | abi | 21:58 |
parazyd | yes | 21:58 |
freemangordon | hmm | 21:58 |
parazyd | the look isn't the problem, i mean everything will be running inside hildon anyway | 21:59 |
parazyd | it's just the calls | 21:59 |
KotCzarny | as a bonus, those old gtk2 apps might get few new features, fe. pannable areas? ;) | 21:59 |
bencoh | waitamin, there is an independent devuan-maemo repo? | 21:59 |
KotCzarny | pretty handy with touch screens | 22:00 |
freemangordon | bencoh: WIP | 22:00 |
parazyd | bencoh: there will be | 22:00 |
DocScrutinizer05 | that's the idea | 22:00 |
parazyd | freemangordon: we'll be free to experiment in any case. that's the point of the thing. the repo is separate from devuan, and we just include the pacakges we want | 22:01 |
parazyd | then they take precedence over devuan's | 22:01 |
DocScrutinizer05 | just like CSSU | 22:01 |
DocScrutinizer05 | well, technically different, but same effect | 22:02 |
Wizzup | freemangordon: I'd be fine with (1) for now | 22:02 |
freemangordon | parazyd: well, forward-porting all hildon gtk stuff for the sake of experiment... a bit of an overkill :) | 22:02 |
Wizzup | I'd go with relatively little effort for now, unless it means -a lot more work- in the future | 22:03 |
Wizzup | this just sounds like an ugly hack, but not something that will bite us anytime soon | 22:03 |
freemangordon | parazyd: ah, BTW which of those 2 options you dislike less? | 22:03 |
DocScrutinizer05 | Wizzup: that's a good approach | 22:03 |
freemangordon | Wizzup: yes, gtk2 private structures won;t change | 22:03 |
parazyd | always less code | 22:03 |
freemangordon | though I am not sure it will be less code, as I'll have to override almost all of the class functions | 22:04 |
DocScrutinizer05 | ((<parazyd> yeah i think DocScrutinizer05 is talking about _all_ the software from the repos...)) of course. And I don't see freemangordon not doing so | 22:05 |
DocScrutinizer05 | maybe I missed the point | 22:05 |
*** LouisA has joined #maemo | 22:05 | |
DocScrutinizer05 | that's why I insist in armel instead armhf images | 22:05 |
bencoh | ... | 22:06 |
DocScrutinizer05 | which are admittely a tad less effective, but according to studies quoted on debian wiki, "up to 40% faster for **heavily numbercrunching** apps" OWTTE | 22:07 |
freemangordon | Wizzup: parazyd: the correct way is to fork gtk2, this is for sure. Maybe I'll just bite the bullet and do it. | 22:07 |
freemangordon | parazyd: If I choose that route, do you know which git repo shall I use as a base? debian? or there is devuan repo for all the stuff? | 22:09 |
*** florian has quit IRC | 22:09 | |
parazyd | we haven't forked gtk2 | 22:09 |
parazyd | but you should do an apt-get source from devuan to be sure you have the right thing | 22:10 |
DocScrutinizer05 | while possibly it's irrelevant for the particular app if itself is softfp or hf build, and different apps may coexist, I see problems in libs and in task scheduler when both are used in parallel | 22:10 |
*** xes_ has joined #maemo | 22:12 | |
DocScrutinizer05 | if we could maje sure all lib ABIs are agnostic of softfp vs hf and the task switcher in scheduler will take care of *all* registers (incl FP), it *might* even work to run armel apps in a hf environment, as long as the softfp libs are available | 22:12 |
DocScrutinizer05 | disclaimer: AIUI | 22:13 |
DocScrutinizer05 | (if softfp are even shared object libs and not embedded code by gcc during build time) | 22:14 |
freemangordon | Wizzup: parazyd: seems I am not the only one https://git.javispedro.com/cgit/topmenu-gtk.git/tree/module/menuitem-proxy.c#n138 :) | 22:14 |
freemangordon | and this is in debian repos | 22:14 |
*** xes has quit IRC | 22:15 | |
freemangordon | ok, going the hacky way for now | 22:15 |
DocScrutinizer05 | freemangordon: would you know if the armel scheduler saves (and restores) the FP registers on task switching? | 22:16 |
DocScrutinizer05 | also I hope all kernel tasks preserve FP as well | 22:17 |
freemangordon | don't know, sorry, but in theory all regs should be saved | 22:18 |
DocScrutinizer05 | ack, thought as much | 22:18 |
freemangordon | along with all the state | 22:18 |
DocScrutinizer05 | trying to wrap my head around that damn soft(fp) vs hf thing | 22:19 |
DocScrutinizer05 | and armel vs armhf | 22:19 |
KotCzarny | fmg: why not maemo's gtk? | 22:19 |
DocScrutinizer05 | I recall back with meego it was like 2 weeks of arguing | 22:19 |
freemangordon | KotCzarny: in what regard? | 22:20 |
freemangordon | what to do with maemo's gtk? | 22:21 |
*** florian has joined #maemo | 22:22 | |
KotCzarny | to take it as a fork base | 22:25 |
freemangordon | it is old | 22:25 |
KotCzarny | it is, unfortunatelly | 22:26 |
DocScrutinizer05 | it worked, so far | 22:26 |
KotCzarny | quite a lot of packages would require newer one | 22:26 |
DocScrutinizer05 | there's always "quite a lot of packages that require newer than X version of Y" out there | 22:27 |
KotCzarny | as in: most of them (from devuan binary repos) | 22:27 |
*** mp107 has joined #maemo | 22:50 | |
*** mp107 has quit IRC | 23:13 | |
*** sunshavi has joined #maemo | 23:26 | |
*** shentey has joined #maemo | 23:43 | |
*** dafox has quit IRC | 23:52 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!