<_uvos_>
freemangordon: i dont think there is a bug
<_uvos_>
its just impossible for dbus activation to work
<_uvos_>
since there is just the one xterm dbus interface, but we have several seperate apllications running in xterms
<_uvos_>
there is no way for the interface to work as desinged, as there is no way for it to know what application needs activation
ceene has quit [Read error: Connection reset by peer]
_CN_ has joined #maemo-leste
<_uvos_>
so short of having xterm crate a different service for eatch application i dont see how a solution is possible besides just not using dbus activation for xterm
_uvos_ has quit [Quit: _uvos_]
<freemangordon>
uvos: and who and why tries to activate xterm?
_uvos_ has joined #maemo-leste
<_uvos_>
freemangordon: hildon
<freemangordon>
you mean - there are xterms, and you click on the launcher icon?
<_uvos_>
so we have 1 application running in an xterm
<freemangordon>
gui application?
<_uvos_>
this xterm was launched on behalf of this application
<freemangordon>
ok
<_uvos_>
because its termnial=true
<freemangordon>
ok
<_uvos_>
in .desktop
<freemangordon>
yeah, got it
<_uvos_>
then the user wants a xterm
<_uvos_>
right then the problem happens
<freemangordon>
lemme check how that works in fremantle
<_uvos_>
in freemantle terminal=true is not supported
<_uvos_>
we added that
<freemangordon>
does not matter
<freemangordon>
you still can start htop or mc
<freemangordon>
starting mc from the launcher starts mc in osso-xterm, trying to start osso-xterm after that brings mc on top
<freemangordon>
that's correct
<freemangordon>
if you want another terminal, you shall start it with "new" anyways
<_uvos_>
i think this is bad
<freemangordon>
no
<freemangordon>
this is by design and sane behaviour imo
<_uvos_>
its not sane at all imo
_CN_ has quit [Ping timeout: 272 seconds]
<freemangordon>
only one copy of xterm can be started from the launcher, no matter if something runs there or not
<_uvos_>
if i click on xterm i want xterm not nmcpp or whatever
<freemangordon>
no, this does not work like that
<freemangordon>
new osso-xterm is launched from the menu
<freemangordon>
not from the launcher
<freemangordon>
new as in "new after the first"
<_uvos_>
well yeah but osso-xterm is several different applications if its launched via .desktop termnial=true
<freemangordon>
also, see what ctrl-shift-x does
<_uvos_>
the fact that this application is running in an xterm is just an implemnentation detail
<_uvos_>
this is really broken if only one xterm is allowed
<freemangordon>
it opens new terminal even if there is already running one
<freemangordon>
I think you are getting this wrong
<freemangordon>
you *can* open new terminals
<freemangordon>
just not from the launcher
<_uvos_>
since by your method whenerver one terminal=true app is running
<_uvos_>
all .desktop files with terminal=true are broken
<_uvos_>
its just broken behavior
<freemangordon>
what do you mean "broken"?
<_uvos_>
they tont work
<_uvos_>
you cant launch nmcpp while htop is running
<_uvos_>
via its .desktop file
<_uvos_>
the dekstop file is broken
<freemangordon>
well then, the issue is with "terminal=true" support, not with xterm
<_uvos_>
untill all xterms are closed
<_uvos_>
no
<_uvos_>
because again
<freemangordon>
check how ctrl-shift-x opens new terminal
<_uvos_>
yes i know
<_uvos_>
it uses dbus
<freemangordon>
the same shall be done for "terminal=true" IIUC
<freemangordon>
so?
<_uvos_>
the fact that htop runs in xterm is a im9plementation detail
<_uvos_>
it shal not change the bavior of the xterm .desktop file either
<_uvos_>
thats jus assinine
<_uvos_>
*just
<freemangordon>
do I get it right that we discuss some imaginary distro with hildon and without osso-xterm?
<_uvos_>
no
<freemangordon>
sorry, I don;t really understand the issue then
_uvos_ has quit [Quit: _uvos_]
<freemangordon>
hildon-desktop shall call libhildonmime finctions to try dbus activation, if it fails, then it shall do what it does now (running osso-xterm directly, IIUC)
_uvos_ has joined #maemo-leste
<freemangordon>
or rather osso-rpc
<freemangordon>
not libhildonmime
<freemangordon>
_uvos_: right now hildon just executes osso-xterm, right?
<_uvos_>
except that dosent work for this case at all
<freemangordon>
WTYM?
<freemangordon>
what exactly does not work?
<_uvos_>
as xterm can have serval personalities depening of it it was launched for the user
<_uvos_>
or on behalf of some other application as an implementation detail
<freemangordon>
ok
<freemangordon>
ok, lemme try to explain my idea:
<_uvos_>
anyhow this is useless i allready know your never going to reccognize the problem as its a design flaw in freemantle
<_uvos_>
and we cant have those
_uvos_ has quit [Client Quit]
<freemangordon>
_uvos_: do you get disconnected or you don;t want to discuss?
Twig has quit [Ping timeout: 272 seconds]
belcher has quit [Ping timeout: 276 seconds]
belcher has joined #maemo-leste
pere has quit [Ping timeout: 240 seconds]
pere has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
pere has quit [Ping timeout: 240 seconds]
pere has joined #maemo-leste
macros_2ndPC has joined #maemo-leste
Daanct12 has quit [Quit: Leaving]
macros_ has quit [Ping timeout: 260 seconds]
_CN_ has joined #maemo-leste
pere has quit [Ping timeout: 276 seconds]
sunshavi_ has left #maemo-leste [ERC Version 5.3 (IRC client for Emacs)]
sunshavi has quit [Remote host closed the connection]
_CN_ has quit [Ping timeout: 246 seconds]
pere has joined #maemo-leste
stlucas__ has quit [Quit: Leaving]
noidea_ has joined #maemo-leste
ceene has joined #maemo-leste
xmn has joined #maemo-leste
uvos has joined #maemo-leste
ceene has quit [Remote host closed the connection]
<norly>
_uvos_, freemangordon: i can confirm this xterm bug.
<norly>
launching htop from the hildon app meny first, then xterm from the app menu, doesn't open the second xterm window
<norly>
however the converse works: opening xterm first, then opening htop from the app menu results in two windows.
Livio has joined #maemo-leste
<uvos>
right the htop desktop file dosent use dbus activation
<Wizzup>
isn't that how it works on fremantle?
<Wizzup>
the only way to open another xterm is to use the menu
<uvos>
Wizzup: yes it is
<uvos>
Wizzup: the problem is this becomes broken when you launch .desktop files that implicitly open xterm
<Wizzup>
oh
<uvos>
ie launch htop or whatever
<Wizzup>
yeah that's a problem
<uvos>
then when you want to launch xterm....
<freemangordon>
I think a proper fix is to not register xterm as osso-service when launched by h-d because of 'terminal=true'
<freemangordon>
maybe additional cmdline paramater or something
<freemangordon>
*parameter
<Wizzup>
right
<freemangordon>
not to say I think this is already implementd
<freemangordon>
so, h-d shall start osso-xterm through dbus, by using "run_command"
<freemangordon>
this opens new terminal window and executes whatever needed, IIUC
<uvos>
this dosent help
<freemangordon>
why?
<freemangordon>
IIUC the particular issue is that you cannot start more than one applications with "terminal=true"
<uvos>
its still broken since the xterm desktop file will still focus a random application window instead of creating the "first" xterm window
<uvos>
no its not
<uvos>
this works fine
<freemangordon>
uvos: look at the code
<uvos>
since hildon dosent use dbus activation for desktop files without the x-osso-whatever key
<freemangordon>
well, we can teach it to do so for "terminal=true"
<freemangordon>
and this will be a proper fix - new window will be opened and it will get focus
<uvos>
then it would break it again
<uvos>
it works _now_ since it dosent use dbus activation
<uvos>
the problem comes if you launch the osso-xterm desktop file only
<uvos>
with the special key
<uvos>
since it dose use dbus activation
<uvos>
activating a random xterm launched by terminal=true
<freemangordon>
ok, thats another issue then
<freemangordon>
do you have example desktop file/application?
<uvos>
any deksktop file with terminal=true works fine here to repo
uvos has quit [Quit: Konversation terminated!]
<freemangordon>
uvos: ok, to summarize:
<freemangordon>
1. h-d support for terminal=true shall be changed to use dbus "run_command" method
<freemangordon>
2. we can change osso-xterm to not focus (the first opened) terminal window but to create another window if needed, though I don't see why we shall do that given that you can always start "new" window from xterm menu
<freemangordon>
hmm, most-probably if we start osso-xterm for terminal=true in such a way that it does not register itself as dbus service will fix (2) too
<freemangordon>
norly: this is not a bug, this is by design
<freemangordon>
BTW the same happens on fremantle: if you start mc and then you start osso-xterm, mc is window is activated
<freemangordon>
*mc window is activated
<freemangordon>
but then again, you can always start new terminal from the menu
<norly>
freemangordon: this is totally unexpected and confusing
<norly>
but i see you already have ideas, so thanks a lot!!
<freemangordon>
norly: ever used fremantle?
<norly>
freemangordon: yes, but i haven't gotten around to set it up again to compare, sorry :(
<norly>
in any case, leste is evolving at an amazing pace, and even that already feels like being back home (like fremantle). so thank you so much.
<freemangordon>
Wizzup: uvos: what about adding another dbus method ('terminal'?) to osso-xterm that is used by h-d to start terminal=true applications and that sets a property ("no_focus_on_activation'?) of the particular window, so when dbus activation is requested, windows with this property to be excluded. if we have no available window to be activated, create a new one.
<norly>
freemangordon: that sounds great, actually!
<norly>
the no_focus_on_activation solution, i mean
Danct12 has joined #maemo-leste
noidea_ has quit [Read error: Connection reset by peer]
noidea_ has joined #maemo-leste
Pali has joined #maemo-leste
Twig has joined #maemo-leste
<tmlind>
uvos: no idea what goes wrong there with the stock kernel.. but sure looks like the uart is not clocked when something is getting printed
uvos has joined #maemo-leste
<uvos>
tmlind: ok, its pretty wierd
<uvos>
tmlind: i just removed all printascii debug prints from kexec modules
<uvos>
its also to big and dosent fit anymore now :(
<uvos>
freemangordon: sure but that seams like a lot of effort for bahvior i think is bad ui anyhow
<Wizzup>
how about other non-terminal apps like contacts?
<uvos>
what about them?
<uvos>
sure contacts being a singleton make sense
<uvos>
same with sphone eg
<uvos>
the terminal? not so mutch
<Wizzup>
is there some xdg key for singleton?
<uvos>
there is a x-osso key
<freemangordon>
uvos: the rationale behind is that no new osso-xterm process is started, just a new window instead
<uvos>
so?
<freemangordon>
so you save on RAM
<uvos>
that dosent enforce the sigelton pattern in the ui wrt ram
<freemangordon>
Wizzup: every osso application is singleton one
<uvos>
really annyoing in other places to btw
<uvos>
like why cant i have to pdf viewers
<uvos>
two
<buZz>
dangit, maemo said 60% battery, i pull the usb cable , plop , shutdown
<freemangordon>
use your laptop
<buZz>
really think my install is kinda crooked again :P
<Wizzup>
maybe we can make it configurable
<freemangordon>
no, please, stop that
<freemangordon>
we have lots of gaps here and there
<Wizzup>
buZz: I think my device also please turns off a bit too quickly with older battery
<buZz>
i think the thresholds might be a bit too tight
<buZz>
or dno
<uvos>
buZz: mce turns it off it it goes below 3.45 volts
<uvos>
its quite conservative
<uvos>
since we cant boot if the voltage is to low
<uvos>
you can lower it a bit if you want
<uvos>
(at the expense of maybe causing to to be unbootable)
<uvos>
also the battery indicator lies if uncallibrated
<freemangordon>
uvos: I am under the impression that you are missing the point of what a mobile OS is
<freemangordon>
this is not server/desktop OS
<uvos>
i dont get why being on mobile should restict me in what windows i can open
<uvos>
but ok
<freemangordon>
because it is resource limited
<uvos>
but
<uvos>
its not
<uvos>
d4 can open hundres of xterms before its out of ram
<freemangordon>
because it opens new windows, not new processes
<freemangordon>
exactly because of the osso service acttivation
<uvos>
not really
<freemangordon>
yes, really
<uvos>
but thats not the point
<freemangordon>
what is tha RAM usage of a single osso-xterm process?
<uvos>
no idea but probubly not more than 4 meg
* freemangordon
checks
<uvos>
besides this is not the point
<Wizzup>
I think fmg says multiple pdf windows is fine, just preferrably not multiple processes
<freemangordon>
exactly
<freemangordon>
on amd64 VM, osso-xterm uses 23644k RES memory according to top
<uvos>
that.. tells us nothing
<freemangordon>
no, that tells us that it uses ~24MBs of RAM
<freemangordon>
"RES stands for the resident size, which is an accurate representation of how much actual physical memory a process is consuming"
<uvos>
no idea where you have that from
<uvos>
but it includes shared
<uvos>
so with what maemo launcher is doing...
<uvos>
also 64bit x86 != 32 bit arm
<freemangordon>
sure
<uvos>
number is mostly useless
<sicelo>
Without entering this discussion, may I mention that on Fremantle i have vim, htop and irssi ... all these have .desktops. i can open them without getting any of them to open in a random existing xterm window.
<freemangordon>
sicelo: yeah... but because they have "hildonized" .desktop files
<freemangordon>
we want to get rid of that
<uvos>
obviously replaceing all the .dekstop files in debian repos is out of scope
<freemangordon>
there is a standard way (terminal=true)
<freemangordon>
uvos: so, back to the matter - besides that it will require some effort to be implementd, do you see any other flaws in my proposal how to fix the issue?
<uvos>
no
<freemangordon>
ok
<freemangordon>
then please opens an issue and assign it to me
<freemangordon>
*open
<buZz>
didnt sliding closed after sliding open used to turn off screen
<buZz>
?
<uvos>
yeah
<uvos>
i had to break this temprarly
<uvos>
mce dose this
<freemangordon>
buZz: auto-lock is broken too in -devel
<freemangordon>
but uvos said he'll fix it when he has some time
<uvos>
freemangordon: ill do it right after i get my device to boot again with sim
<uvos>
autorelock is harder
<freemangordon>
uvos: sure, I didn;t mean to sound offensive or something
<uvos>
freemangordon: no worrys
<freemangordon>
just explaining the situation
<uvos>
buZz: so mce relocks whever no input event was caused, except for events that are ignored
<uvos>
buZz: unfortionatly mce chooses events to ignore based on which device they come frome
<uvos>
buZz: unfortionaly on d4 the slider key and the volume buttons are on one deivce
<uvos>
buZz: you can have it ignore the volume buttons, or you can have it not ignore the slider key as an "input" for autorelock
<uvos>
you cant have both
<uvos>
atm
<buZz>
ah ok, cool , np
<freemangordon>
uvos: do you want me to look at this?
<uvos>
freemangordon: no its fine
<freemangordon>
ok
<uvos>
i just have to replace the filter system with soemthing that filters per key code instead of per device
<uvos>
its on my list
<freemangordon>
right
vagag has joined #maemo-leste
uvos has quit [Remote host closed the connection]
Twig has quit [Ping timeout: 276 seconds]
uvos has joined #maemo-leste
<uvos>
tmlind: not ever loading the uart module dosent help either :|
<uvos>
tmlind: so there is a bug in stock kernel uart subsystem that somehow triggers on kexec
<uvos>
tmlind: (with this sim)
<uvos>
really strange
<uvos>
tmlind: well im at a loss
<uvos>
tmlind: ill go with echo shutdown > /sys/class/radio/mdm6600/command; sleep 5 for now
<uvos>
that makes it boot reliably at least
norayr has left #maemo-leste [Error from remote client]
<Wizzup>
honeycomb builds are now working on armhf, adding arm64 now
<Wizzup>
the speed beats the amd64 builds :)
<uvos>
Wizzup: great
<norly>
is there an easy way to have a mouse pointer when running the x86 build in a VM?
<norly>
as in, to have it *visible*?
<norly>
ah, got it. invoking qemu with -display gtk,show-cursor=on should do the trick :)
crab has quit [Remote host closed the connection]
crab has joined #maemo-leste
mardy has quit [Quit: WeeChat 2.8]
<norly>
next question then... F7/F8 are mapped to the volume keys. but when running the VM, is there a key to turn on the virtual screen again after it went to sleep?
<uvos>
F7/F8 are not mapped to the volume keys
<uvos>
just some applications react to f7/f8 the same as volume
<uvos>
anyhow
<uvos>
its by pressing the acpi power button
<uvos>
how thats done on your vm varies
sunshavi has joined #maemo-leste
<uvos>
freemangordon: new mce version should be fine wrt autolock
<uvos>
freemangordon: but dident test beacuse i use the newer cp applets that do not use the gconf if anyhow (so setting autolock works either way)
<Wizzup>
uvos: can you check the mce arm64 build
<Wizzup>
uvos: I am not sure if it's my changes or something in mce
<uvos>
none of the depends changed
<uvos>
so i dont see how it can be a change in mce
<Wizzup>
hmm
<Wizzup>
armhf worked fine though
<Wizzup>
and they are the same setup
<Wizzup>
maybe just retry?
<uvos>
its not finding any packges
<uvos>
looks like
<Wizzup>
ok
<uvos>
from leste repo
<uvos>
is it maybe missin in sources.list somehow?
<uvos>
sure i can retry that dosent cost anything
<Wizzup>
try again?
<Wizzup>
yeah
<Wizzup>
I just made a change
<Wizzup>
maybe not in time
<Wizzup>
let's see
<uvos>
still failing
<Wizzup>
oh I see..
<uvos>
hmm?
<Wizzup>
I missed a config file
<uvos>
ready?
<Wizzup>
I started it
<Wizzup>
ty
<uvos>
ok
<uvos>
thanks
<Wizzup>
note it might still fail but that should be a predictable one
<Wizzup>
it will build the pbuilder env now
<Wizzup>
and then I will chroot and add the keys (one time thing)
<Wizzup>
yup
<uvos>
not sure what your doing there but im sure youl make it work :P
<Wizzup>
it should work this time
<Wizzup>
i've just been reverse engineering the bash history of root on the build pis that parazyd set up
<uvos>
lol
<Wizzup>
*shrug*
<Wizzup>
it works
<uvos>
maybe write it down this time
<Wizzup>
I have
<uvos>
good :)
<Wizzup>
both are set to 8GB ram and 6 cores
<Wizzup>
could increase it some but I don't want to fully hit the machine yet
<uvos>
ok
<uvos>
probubly the storage io speed is the biggest gain here tho
<uvos>
on the pis most of the time installing the packages took more time than the compile
<Wizzup>
yes
<Wizzup>
the speed is also 3x at least
<Wizzup>
going to sleep soon, but glad this is finally done
freemangordon has quit [Ping timeout: 245 seconds]
Livio has quit [Ping timeout: 250 seconds]
sunshavi has quit [Ping timeout: 256 seconds]
freemangordon has joined #maemo-leste
inky_ has joined #maemo-leste
vagag has left #maemo-leste [#maemo-leste]
arno11 has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
uvos has quit [Ping timeout: 240 seconds]
<norly>
uvos: thanks!
xes has quit [Ping timeout: 246 seconds]
sunshavi has joined #maemo-leste
<norayr>
people
<norayr>
i don't know... i have so many questions...
<norayr>
i understand you are busy but i am ignored for several days.
<norayr>
:/
<norayr>
one question was about the new boot loader entry.
<norayr>
i have read here something about it. and now my droid, today, drained the battery. and i again remembered about my question.
<norayr>
someone mentioned there is a new menu entry
xes has joined #maemo-leste
<norayr>
that may charge the droid. and i asked if that menu option is a part of new maemo leste image?
<norayr>
i guess it is not. it is part of that bootloader, kexecboot, i guess was it's name.
<norayr>
so it is separate from the leste image right?
<norayr>
then having a new image won't help me.
<norayr>
another question was about the messages i get when i boot leste.
<norayr>
it tells me to remove /etc/init.d/zram, and deactivate the service. but it also tells that zram situation improved, so i am confused.
<norayr>
i guess that option should be part of droid4-kexecboot.img?
<norayr>
(back to the first question)
<norayr>
if i manage to starte droid, i probably have to backup the home data, and install the new image... to understand everything is right with zram.
<norayr>
but then, will i use data about my wifi access points? where is it located? in my home? or somewhere in /var directory?
norayr has left #maemo-leste [Disconnected: Received SIGTERM]