On Sat, 7 Nov 2009 14:44:53 +0100 Nicola Mfb <nicola....@gmail.com> said:
> On Sat, Nov 7, 2009 at 1:55 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > [...] > > yes. see above. apps are doing it all the time. it's about the most standard > > way to provide information about your window, from title to minimum and > > maximum size to aspect ratios and more. rotation preferences are just yet > > more properties like this. if its a "property" of the window - put it as a > > property of the window. use the mechanism created for precisely this kind > > of thing. dbus is not that mechanism. > [...] > > if an app has rotation preferences, it should set them. if it has none - it > > gets whatever the screen has right now - or whatever the wm chooses to > > implement as policy. yes - you modify apps to have them indicate their > > preferences. otherwise they are deemed to "not care" which is the case now, > > for example. you modify the apps - thats the right way to do it. you don't > > post-mortem find a way to hack things in. :) > > > >> Also do you know if there's already a well-known window property for > >> preferred rotation, or would we be inventing a new one? > > > > you'd be inventing it. > > I agree that window properties is the right way to implement that, but > we need a way to get rotation preferences now, while that may be > proposed and discussed as a standard for the future. thats the job of the wm to implement the rotation and a policy (preferences) *IF* an app desires something specific - it is up to the app to say so. until it does it can be assumed to have no preference. > So a couple of questions: > > * is it possible/safe/correct to set a window properties of a > window/xclient by an external app (e.g. a launcher)? it is. but it's wrong. it's silly. it's a horrible hack. you do not need it. that app HAS no preferences. it was never written to be just landscape or just portrait. it HAD to have been written to work in either mode. it had no choice. your assumption here is wrong :) > * supposing the above is possible, we may add a custom configuration > entry in .desktop files and delegate the launcher to set window > properties this is just silly. you are modifying the app - you are modifying the .desktop file. the code here is several times bigger than modifying the app. it's a horrible hack. don't do it. > * if that is not possible the wm or an ewmh app helper (the launcher > itself?) may get the active current window and perform the screen > rotation as needed as such - until an app window hints otherwise - rotate as desired. if it hints that it would like to be a specific rotation, then enforce that rotation if it is not in effect yet. :) > In every case and going a bit ot, is anyway possibile having a generic > Window ID to retrieve the .desktop file originating the owning app? this is a complicated mess. a window id is like a pointer. knowing who allocated it is tricky. as such its not guaranteed to be able to know UNLESS the app alrady does a chunk of work and sets a bunch of properties etc. etc. and the wm tracks pid's launch id's matches these up with window properties etc. etc. - e does this. .desk to files are NOT the place for things like this. absolutely not the place. you will be abusing a mechanism not designed for this. i can tell you that i'd never accept a patch that does this - and most wm authors i know would not. you'd never get this through as a standard on freedesktop.org. because it's wrong. > I'm just guessing to retrieve the pid from window properties, retrieve > the executable (like /proc/pid/exe) and back search in the .desktop > file definitions. not always possible. setting pid is optional for an app. even then - if the pid of the app is not the pid of what you launched (you launched a shell script that runs 1 or more child procs - thus have different pid's) you are screwed. it's an inexact breakable mechanism. i repeat. don't use it. not going to send more mails about not using it. i've said it often enough. :) > But this seems weight as the Exec in .desktop files may be a relative > path, a link etc, for sure there is a better way, may you explain > them? the app sets the property if it cares. it it's code. otherwise - too bad. thats the better way. > Thanks and Regards > > Nicola > > _______________________________________________ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
