RE: [maemo-developers] RFC: Redesigning the HildonApp+Views
Hi, >> A design document is available here: >> https://stage.maemo.org/svn/maemo/projects/haf/doc/hildon-window/ > >Umm... it seems thi directory requires authentication!? Yes, but the username is always guest and password guest when you want just checkout or read the contents. Committing things is another issue, only package maintainers can do commits (in my area: me and Johan) but we are accepting patches from OSS community (also) if someone provides suitable ones. Also suggestions and ideas are all along very welcome. Best Regards, Karoliina http://www.karoliinasalminen.com/blog ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] RFC: Redesigning the HildonApp+Views
Hi, Nils Faerber wrote: > Umm... it seems thi directory requires authentication!? guest/guest... but it might be a good idea to drop this "feature" if possible. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] RFC: Redesigning the HildonApp+Views
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Johan Bilien schrieb: > On Fri, Dec 16, 2005, Tommi Komulainen wrote: > >>There's a bit of a problem. People want more eyecandy and flashy >>gimmicks related to application windows, but the current design makes >>those things difficult to implement without making a big mess. >> >>Therefore we're going to implement new widget(s) in parallel with the >>current HildonApp and HildonAppView that would support those new >>features. Existing applications will not be affected, but they won't be >>getting the benefits either. Eventually App+Views are going to be >>deprecated and dropped altogether. > > > The design and implementations are now well on the way. But before we > proceed with an API freeze, we would to ask again for feedback on the > design decisions and current API. > > A design document is available here: > https://stage.maemo.org/svn/maemo/projects/haf/doc/hildon-window/ Umm... it seems thi directory requires authentication!? > Thanks, Cheers nils faerber - -- kernel concepts Tel: +49-271-771091-12 Dreisbachstr. 24 Fax: +49-271-771091-19 D-57250 Netphen Mob: +49-176-21024535 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFDz7w6JXeIURG1qHgRAk2eAJQMhpyjNadD26cvqbaJ0tY0bSV6AKDisKRl BzL+fffbHRalQn/nD2/iMg== =YWis -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] RFC: Redesigning the HildonApp+Views
On Fri, Dec 16, 2005, Tommi Komulainen wrote: > There's a bit of a problem. People want more eyecandy and flashy > gimmicks related to application windows, but the current design makes > those things difficult to implement without making a big mess. > > Therefore we're going to implement new widget(s) in parallel with the > current HildonApp and HildonAppView that would support those new > features. Existing applications will not be affected, but they won't be > getting the benefits either. Eventually App+Views are going to be > deprecated and dropped altogether. The design and implementations are now well on the way. But before we proceed with an API freeze, we would to ask again for feedback on the design decisions and current API. A design document is available here: https://stage.maemo.org/svn/maemo/projects/haf/doc/hildon-window/ Your comments are greatly appreciated, on this list or on the wiki: http://maemo.org/maemowiki/HildonAppViewRewrite?action=show Thanks, -- Johan Bilien [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] RFC: Redesigning the HildonApp+Views
Komulainen Tommi (Nokia-M/Helsinki) ([EMAIL PROTECTED]) wrote: > On Sat, 2005-12-17 at 01:27 +0100, ext Simon Budig wrote: > > Right now the code has to dive into different codepaths for native GTK > > vs. Hildon, so that hildon gets an appview into the window and the rest > > of the UI gets packed into the appview, it would be cool to get rid of > > that need. > > Having the new widget derive directly from GtkWindow should help in > that. However you will still need to do handle menus and toolbars > slightly differently. True. However, it is a noble goal to try to keep the differences to a minimum :) > > For me the semantics of having multiple appviews is more like a big > > GtkNotebook with invisible tabs. If the individual appviews should > > appear in the task switcher might depend on the application and might > > need to use an additional method to inform the task switcher about the > > appviews, the task switcher then probably should display the appviews in > > a kind of menu. It confuses the heck out of me to see two globes in the > > task switcher, click on the lower one and suddenly the upper one gets > > active (yeah, I know it is not like that, but it looks like that). > > Well, the TN does know the application and how many views it has and > shows them in the task switcher without any additional menu. The problem > with identical icons is one of the reasons we want the new widget - > custom icons come naturally with the windows, but supporting the same > thing with appviews would be painful. Yeah, that would be solved automatically if each Appview has its own GtkWindow (or whatever the new approach is). Some Windowmanagers (or panel applets) implement a grouping-by-application mechanism, so that the number of buttons in the panel is kept to a minimum. Something like this would help the TN as well, especially since there is only room for four or five icons. > > Oh yeah - GIMP-like coding style for the headerfiles and the code :-) > > Ooh, let the coding style wars begin! I'm familiar with GNOME and gtk+ > coding style, how does gimp style relate to those? :) Heh :) Actually I am just reading the Gnome coding styleguide and I am surprised that they suggest 8-space tabs. That is IMHO too much, but I don't really want to discuss this... :) The gimp coding style is basically GNU coding style with a few extensions, see the "Hackordnung" at http://developer.gimp.org/HACKING . Without really looking into it I'd guess that GTK+ is very similiar. When reading the hildon header files there are two things that bug me most: The lack of a space before an opening parenthesis (which makes it harder to separate the function name from the first arguments type) and the lack of vertical alignment. For an experiment try to quickly spot all the function names declared in http://www.home.unix-ag.org/simon/files/n770/hildon-app.orig.h (which is an unmodified copy of the original file) and then try the same with http://www.home.unix-ag.org/simon/files/n770/hildon-app.indent.h where I have applied some GIMP coding style :) (most notably the vertical alignment, which is - as I realize now - not explicitely mentioned in the Hackordnung). Anyway - as you say, this is a can of worms and it is sometimes fun to open one, but don't let that distract us from the bigger issues :) Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] RFC: Redesigning the HildonApp+Views
On Sat, 2005-12-17 at 01:27 +0100, ext Simon Budig wrote: > Hi. > > Tommi Komulainen ([EMAIL PROTECTED]) wrote: > > Essentially the change would be to introduce a new widget (maybe > > HildonWindow or something) that would replace current HildonAppView. The > > new widget would be a real GtkWindow / toplevel X window which will > > require code changes when migrating the the new API, but in the longer > > term, once we drop the old views, reduce overall complexity. > > Yeah, the concept of multiple views in an app struck me odd. I can see > reasons for having multiple views, but I don't see what is the benefit > over having multiple "GtkWindows" aka HildonApps. Hysterical raisins. We needed to have application modal dialogs and at that time introducing the concept of "views" was more simple. These days it's more simple to make the window manager do it. > Right now the code has to dive into different codepaths for native GTK > vs. Hildon, so that hildon gets an appview into the window and the rest > of the UI gets packed into the appview, it would be cool to get rid of > that need. Having the new widget derive directly from GtkWindow should help in that. However you will still need to do handle menus and toolbars slightly differently. > > * unmodified gtk+ applications using GtkWindows will be accessible > > through the task switcher > > This cannot be solved by a new widget. This needs to be solved at the > taskswitcher-level, preferrably by implementing the relevant parts of > the freedesktop wm-spec standards. This will give you a list of the top > level windows and you then can retrieve the icons as provided by the > application. You're of course correct. I left that bit out basically because the specs already exist, so there's not much more effort needed there - only to reuse what's already there. > > * the new API should be as similar (toolbars) as possible, or in > > places more sane (key handling, fullscreening) than with > > AppViews > > Just from looking at the hildon header files: deprecate > hildon_appview_set_fullscreen() and use gtk_window_(un)fullscreen() > instead. > > Yeah, I am aware that an appview is not a window, but this is something > that needs to be cleared up. It does not really make sense to have two > appviews that both belong to the same hildonapp (read GtkWindow) and one > is fullscreen and the other is not. You shouldn't think of views as anything fancy, they're just an implementation detail. Logically they're just windows, though you can only ever see one at a time. I think it is better to have that option, then you have more options to do application UI design. Whether that design is a good one is a different question :) > For me the semantics of having multiple appviews is more like a big > GtkNotebook with invisible tabs. If the individual appviews should > appear in the task switcher might depend on the application and might > need to use an additional method to inform the task switcher about the > appviews, the task switcher then probably should display the appviews in > a kind of menu. It confuses the heck out of me to see two globes in the > task switcher, click on the lower one and suddenly the upper one gets > active (yeah, I know it is not like that, but it looks like that). Well, the TN does know the application and how many views it has and shows them in the task switcher without any additional menu. The problem with identical icons is one of the reasons we want the new widget - custom icons come naturally with the windows, but supporting the same thing with appviews would be painful. > Oh yeah - GIMP-like coding style for the headerfiles and the code :-) Ooh, let the coding style wars begin! I'm familiar with GNOME and gtk+ coding style, how does gimp style relate to those? :) -- - Tommi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] RFC: Redesigning the HildonApp+Views
Hi. Tommi Komulainen ([EMAIL PROTECTED]) wrote: > Essentially the change would be to introduce a new widget (maybe > HildonWindow or something) that would replace current HildonAppView. The > new widget would be a real GtkWindow / toplevel X window which will > require code changes when migrating the the new API, but in the longer > term, once we drop the old views, reduce overall complexity. Yeah, the concept of multiple views in an app struck me odd. I can see reasons for having multiple views, but I don't see what is the benefit over having multiple "GtkWindows" aka HildonApps. When we are talking about the ease of porting it should be possible to hide the differences between native GTK and Hildon in some #defines, like e.g. this: window = g_object_new ( #ifdef HILDON HILDON_TYPE_APP, "app-title", "Sudoku", #else GTK_TYPE_WINDOW, #endif "type", GTK_WINDOW_TOPLEVEL, "events", GDK_KEY_PRESS_MASK, "title", "Sudoku", NULL); Of course it is a personal preference thing to #ifdef the whole call to g_object_new(), but I think you see the point. Right now the code has to dive into different codepaths for native GTK vs. Hildon, so that hildon gets an appview into the window and the rest of the UI gets packed into the appview, it would be cool to get rid of that need. > Below is a rough, unordered list of goals for (or because of) the new > widget. Feel free to comment if you think there's something important > missing: Some random thoughts on the points you raise. > * unmodified gtk+ applications using GtkWindows will be accessible > through the task switcher This cannot be solved by a new widget. This needs to be solved at the taskswitcher-level, preferrably by implementing the relevant parts of the freedesktop wm-spec standards. This will give you a list of the top level windows and you then can retrieve the icons as provided by the application. > * porting from GtkWindows to the new API should be trivial to get > the basic looks, not more complicated than currently to get the > toolbars etc. look and feel as with AppViews See above for an approach with #define, I think this is quite trivial. If it would be necessary to have a different widget hierarchy it becomes more of a hurdle. > * the new API should be as similar (toolbars) as possible, or in > places more sane (key handling, fullscreening) than with > AppViews Just from looking at the hildon header files: deprecate hildon_appview_set_fullscreen() and use gtk_window_(un)fullscreen() instead. Yeah, I am aware that an appview is not a window, but this is something that needs to be cleared up. It does not really make sense to have two appviews that both belong to the same hildonapp (read GtkWindow) and one is fullscreen and the other is not. For me the semantics of having multiple appviews is more like a big GtkNotebook with invisible tabs. If the individual appviews should appear in the task switcher might depend on the application and might need to use an additional method to inform the task switcher about the appviews, the task switcher then probably should display the appviews in a kind of menu. It confuses the heck out of me to see two globes in the task switcher, click on the lower one and suddenly the upper one gets active (yeah, I know it is not like that, but it looks like that). Thats it for now - I'll followup if something else comes to my mind. Oh yeah - GIMP-like coding style for the headerfiles and the code :-) Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
