Re: Proper Way To Call Browser (Fremantle)
Hi, the browser can be opened by using a dbus-service. The package is called tablet-browser-interface and you find the header in the dev-package. Here is an example how to call the service from the command line: dbus-send --system --type=method_call --dest=com.nokia.osso_browser --print-reply /com/nokia/osso_browser/request com.nokia.osso_browser.load_url string:http://www.google.com; Cheers Daniel ext Brent Chiodo wrote: I am writing an application for Maemo 5/Fremantle that needs to load the browser to a specific page when needed. How would I go about calling the browser? Ideally, I want to open the browser in a new window to a specific page and in the current browser process if there is already one open. Thanks. -- Best Regards, Brent Chiodo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Developer device program
ext tz wrote: I've done the extras for Diablo but haven't for Fremantle since I really need some specific hardware features which aren't quite there in emulation (the underlying code will work anywhere, but the interesting problems will only show up on the target). I hope it isn't a paradox that I can only get the hardware by having apps, but can only really test the apps by having hardware. Just curious, what project(s) are you referring to? What are the showstoppers? Other developers (e.g. those using the accelerometers) have uploaded first versions to Fremantle extras-devel and they actually got the apps quite right after getting some feedback from people with a device. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
karoliina.t.salmi...@nokia.com wrote: If you have custom widgets in every program on a system, users will find it harder to use. They will not know what to expect when they tap on a widget they never saw before... that's the point of having guidelines. Please read my sentences above. I meant about replicating the functionality of the widget done with other technology with another and ending up with exactly the same user experience. It is possible and the guidelines can be followed to create the new widgets. There is nothing that prevents that, it is just some additional work required for the developer as there are hildon widgets lacking from the selection of widgets on the Qt side. Agreed. I've asked Antontio to start a project so we can create a set of hildon-widgets. What would be good would be some collaboration on creating a prioritised list and documenting the required behaviour. http://wiki.maemo.org/Qt4_Hildon#Where_are_the_Hildon_Widgets_for_Qt http://wiki.maemo.org/Qt4_Hildon/Qt_Hildon_Widgets If you compare the kinetic scroll list on the startup wizard to the kinetic scroll list elsewhere, you may find that it functions the same way, despite that is Clutter and elsewhere it is Gtk. Similarly I am sure it can be done also with the Qt in the same way, so that as end user you can't see the difference (except that on different toolkits there may be slight performance differences, e.g. pure clutter can be obviously faster than Gtk and similarly the performance may differ on the Qt version to direction or another depending on the case). It just requires accurate tuning for all the parameters to get the scroll behavior exactly the same and snip What comes to the kinetic scroll list, it has certain little details that are important, otherwise it will feel different (and not right): - edge bounce - easing on edge bounce (the movement decelerates before it stops instead of stopping mechanically) - friction - inertia - scrolling speed (comes from the physics of the friction, inertia, and the initial speed given by the finger) - finger following - item selection sensitivity from touch - item deselection sensitivity from following movement - stoppable movement (despite of high inertia, stopped finger stops the movement immediately) To get these right, it really requires trying out on the device how it feels. When doing the startup wizard we found that some sensitivities (e.g. selection sensitivity) need to be a bit different when operated on mouse than when operated on finger on the device. I (and others) wrote the Qt fingerscroll that we have (had?) in experimental. All those factors are parameters. It also works on any scroll-based widget 'for free' and allows highlighting and drag'n'drop. I completely agree that it needs tuning on the device... sadly I don't have one... but if someone wants to send me one... Once the list is perfected, all the other widgets are easily composited from these lists and other widgets. So it is a good idea to start from making a list on Qt to function exactly like it functions on the Hildon. I've asked Antontio to start a project so we can create a set of hildon-widgets. IIRC we also need to do dbus integration too. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proper Way To Call Browser (Fremantle)
On Mon, Sep 7, 2009 at 07:59, daniel wilmsdaniel.wi...@nokia.com wrote: the browser can be opened by using a dbus-service. The package is called tablet-browser-interface and you find the header in the dev-package. I also tested `browser --url=http://www.google.com' and that worked as well. I suspect the D-Bus approach is better, though? Cheers, -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proper Way To Call Browser (Fremantle)
ext Brent Chiodo wrote: Ideally, I want to open the browser in a new window to a specific page and in the current browser process if there is already one open. daniel wilms wrote: the browser can be opened by using a dbus-service. The package is called tablet-browser-interface and you find the header in the dev-package. Here is an example how to call the service from the command line: dbus-send --system --type=method_call --dest=com.nokia.osso_browser --print-reply /com/nokia/osso_browser/request com.nokia.osso_browser.load_url string:http://www.google.com; Brent, try this too - it shows usage of the interface daniel refers to. http://blogs.gnome.org/tthurman/2009/09/03/writing-apps-for-the-n900-part-1/ I assume C - I'm doing something similar in python later too David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
Hi there, Analizing the hildon widget that people want to have in Qt, I can say that: There are hildon/ized widgets that will be part of Qt itself and Qt hildon widgets that will come from a different lib (not implemented yet). Some essential widgets like Hildon stackable windows and Maemo5 menus will be part of Qt GUI module. They have been already coded and the code is in our git repository. Qt is able to use Hildon Native dialogs (eg: File dialogs). We can support others Hildon dialogs just adding a couple of lines in the style. The rest of hildon widgets that won't be part of Qt itself and they will be part of another project that me, David and maybe other people interested in can do togheter. Ciao, Antonio On Mon, Sep 7, 2009 at 11:06 AM, David Greaves da...@dgreaves.com wrote: karoliina.t.salmi...@nokia.com wrote: If you have custom widgets in every program on a system, users will find it harder to use. They will not know what to expect when they tap on a widget they never saw before... that's the point of having guidelines. Please read my sentences above. I meant about replicating the functionality of the widget done with other technology with another and ending up with exactly the same user experience. It is possible and the guidelines can be followed to create the new widgets. There is nothing that prevents that, it is just some additional work required for the developer as there are hildon widgets lacking from the selection of widgets on the Qt side. Agreed. I've asked Antontio to start a project so we can create a set of hildon-widgets. What would be good would be some collaboration on creating a prioritised list and documenting the required behaviour. http://wiki.maemo.org/Qt4_Hildon#Where_are_the_Hildon_Widgets_for_Qt http://wiki.maemo.org/Qt4_Hildon/Qt_Hildon_Widgets If you compare the kinetic scroll list on the startup wizard to the kinetic scroll list elsewhere, you may find that it functions the same way, despite that is Clutter and elsewhere it is Gtk. Similarly I am sure it can be done also with the Qt in the same way, so that as end user you can't see the difference (except that on different toolkits there may be slight performance differences, e.g. pure clutter can be obviously faster than Gtk and similarly the performance may differ on the Qt version to direction or another depending on the case). It just requires accurate tuning for all the parameters to get the scroll behavior exactly the same and snip What comes to the kinetic scroll list, it has certain little details that are important, otherwise it will feel different (and not right): - edge bounce - easing on edge bounce (the movement decelerates before it stops instead of stopping mechanically) - friction - inertia - scrolling speed (comes from the physics of the friction, inertia, and the initial speed given by the finger) - finger following - item selection sensitivity from touch - item deselection sensitivity from following movement - stoppable movement (despite of high inertia, stopped finger stops the movement immediately) To get these right, it really requires trying out on the device how it feels. When doing the startup wizard we found that some sensitivities (e.g. selection sensitivity) need to be a bit different when operated on mouse than when operated on finger on the device. I (and others) wrote the Qt fingerscroll that we have (had?) in experimental. All those factors are parameters. It also works on any scroll-based widget 'for free' and allows highlighting and drag'n'drop. I completely agree that it needs tuning on the device... sadly I don't have one... but if someone wants to send me one... Once the list is perfected, all the other widgets are easily composited from these lists and other widgets. So it is a good idea to start from making a list on Qt to function exactly like it functions on the Hildon. I've asked Antontio to start a project so we can create a set of hildon-widgets. IIRC we also need to do dbus integration too. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Mike Ditka http://www.brainyquote.com/quotes/authors/m/mike_ditka.html - If God had wanted man to play soccer, he wouldn't have given us arms. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
From: karoliina.t.salmi...@nokia.com These things are easier in some toolkits and harder in some others. To my knowledge, Gtk was not really designed for handheld touch user interface with kinetic scroll etc. on mind in the first place - it is a rather a desktop toolkit with the rather traditional mindset - and some of hard core hacking obviously was required to make it function like it functions on the Maemo 5. That is a great achievement and I have watched that with awe and lots of respect to the developers who have made it. I can now enjoy it every day with my N900, lists etc. work as they should and they make this UI very desirable. For any reason all the times that Qt advantages were mentioned, they always talk about the kinetic scroll support as the big advantage. Right now hildon has kinetic support, as a new container general container was added, HildonPannableArea [1]. In the same way this Hard core hacking is more than debatable. Yes, the current gtk used on maemo 5 has some maemo-specific changes (hardcode hacks?) but this are just to support some different requirements here, and maintained in a different branch in order to not interfere with the normal upstream work on gtk. But most of this changes are being constantly integrated on upstream. On the other hand, it was a lot easier to start the same from scratch on Startup wizard with Clutter because there was not the incompatible way of thinking as a barrier between the desired functionality and what is already there because there was nothing there already, just start from grass root level from atomic blocks (start by building a custom ClutterActor) and then figure out how to stack Actors and how to animated them to get e.g. a kinetic scroll list done. As there was no base widget, there was no limitations of the base widget and no associated problems, just putting some lego blocks together and it was done. With some adjustable parameters and then fine tuning the feel with these parameters, it was actually quite efficient to do it. So you are suggesting that starting from almost scratch, with basically a base widget support, *in general*, is better that start with a toolkit with a lot of tools, because you have the control of all that you want to do, and you can avoid the constraints of the toolkit? In this case, why use gtk or Qt or Clutter? You can use directly OpenGL and make your app. After all, the N900 has EGL support. I believe Qt can be in the same position pretty much, if the widget is started from scratch rather basing it on some existing widget which has similar limitations than the equivalent in the Gtk. Qt is more like Gtk + Clutter combined rather than being equivalent of the Gtk alone. Kate said there is some kinetic scroll list already there in the Qt, but I don't know how its parameters match to the Hildon/Gtk version we have on the Maemo 5, but I think that with some work it can be done to function 100% equally, as it works equally on startup wizard despite it is a completely separate implementation with a completely different kind of technology behind it. And despite of that, it still just works, perfectly. ... I believe you (or anybody else) are very welcome to pixel perfect and fine tune the list performances of the Qt equivalent widgets if someone creates the missing few hildon widget Qt equivalents. But that was the question from the beginning in this thread. Please read the previous comments. Most of the developers were concerned because there are some Hildon-Gtk widgets, that provides a specific functionality, but they doesn't exist on Qt. The question was if the official Qt-Nokia support has the intention to develop this widgets, in order to made easier have the same lookrfeel, or if they are supposed to be created by the apps developers. And few is not exactly the adjetive I would use. [1] https://git.maemo.org/projects/hildon/?p=hildon;a=blob;f=hildon/hildon-pannable-area.h;h=51690e5f12b0b49b4144787652d13f41b18e05b3;hb=HEAD === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder: building svn tags from garage
ext Ed Bartosh bart...@gmail.com writes: I think our internal buildbot (who does order source packages by their dependencies) only looks at the direct dependencies. Yes. And I'm going to use that code in autobuilder without redesigning. At least now. Later on I might consider to implement analyzing binary dependencies, but it will happen only if it's really needed. I doubt that this can be showstopper for first implementation of multiple package builds. Very likely not. We have used that code successfully for a long time already, after all. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
On Sun, Sep 06, 2009 at 07:14:22PM +0200, karoliina.t.salmi...@nokia.com wrote: if you want to have the exact same user experience as the preinstalled Maemo 5 applications have (as seen in all youtube videos and the SDK), then you have much easier time and faster development with the gtk-based hildon widgets in Maemo 5. I would caution against too easily dismissing Hildon Pickers as trivial composites that app developers can implement. [...] The combobox in Linux desktops is pretty much a subset of the hildon pickers (in terms of funtionality, not directly in terms of actual UI elements). So if pickers would be trivial, then why would there be a need to provide a combobox in the standard toolkit? These things are easier in some toolkits and harder in some others. To my knowledge, Gtk was not really designed for handheld touch user interface with kinetic scroll etc. on mind in the first place - it is a rather a desktop toolkit with the rather traditional mindset - and some of hard core hacking obviously was required to make it function like it functions on the Maemo 5. From a technological point of view, the new widgets in Hildon are completely traditional and they are based on standard Gtk+ widgets. Of course they are designed to be used on a small, touch screen device, but what this means in terms of implementation is that we avoided using interactions, components and sizes that were too small or too difficult to be used with fingers in a screen like that of the N900. We haven't found any particular limitation in Gtk+ that made this more difficult. Example: HildonAppMenu is basically a window with two groups of buttons. There's nothing strange or unexpected here, and certainly nothing that Gtk+ was not designed to cope with. The work here was about getting the semantics, layout, sizes, alignments, API, etc right, not about fighting with any design limitation in Gtk+. And the same thing applies to all other Hildon widgets. The importance and the goal of Hildon is to provide a set of essential widgets so a) app developers don't have to waste their time in writing them themselves b) there is UI consistency between all applications If there are no Qt equivalents for all Hildon widgets, none of these two problems are solved, no matter how easy it is for developers to write their own widgets or how compact the code is. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: New apps for fremantle with Qt?
Hi -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of ext Alejandro Garcia Castro Sent: 07 September, 2009 13:19 To: Andrea Grandi Cc: maemo-developers@maemo.org Subject: Re: New apps for fremantle with Qt? On Fri, Sep 04, 2009 at 07:48:15PM +0200, Andrea Grandi wrote: Hi, 2009/9/4 kate.alh...@nokia.com: If some of these composite widgets are so big problem, we can collect these examples as widget library. composed widget are not a problem for ObjectOriented-people :D I guess in that case you should ask Orbit team about those 50 mobile user experience widgets they are implementing over Qt ;): # A new Orbit extension library for Qt, which contains more than 50 widgets tailored for mobile user experience, and which will provide a replacement for the existing Avkon widget set. [1] http://www.nokiamobiletalk.com/2009/07/direct-ui-by-nokia-maybe -coming-soon/ Please also note this mentioned avkon and other things they are saying they would be doing there have very little if nothing to do with Maemo. It is a completely different environment solving a different set of problems. The widget set in S60 is quite different from the Maemo 5. You can easily see that if you compare a S60 phone with N900. Maemo has been and is going to different direction, so I think you can't use that in any valid comparison. Best Regards, Karoliina ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
ext Alejandro Garcia Castro wrote: On Fri, Sep 04, 2009 at 07:48:15PM +0200, Andrea Grandi wrote: Hi, 2009/9/4 kate.alh...@nokia.com: If some of these composite widgets are so big problem, we can collect these examples as widget library. composed widget are not a problem for ObjectOriented-people :D I guess in that case you should ask Orbit team about those 50 mobile user experience widgets they are implementing over Qt ;): Orbit is completely different thing, implement 50 new mobile widgets than just building some composite widget equivalent of Hildon widgets using existing hildonized Qt widgets. Kate # A new “Orbit” extension library for Qt, which contains more than 50 widgets tailored for mobile user experience, and which will provide a replacement for the existing “Avkon” widget set. [1] http://www.nokiamobiletalk.com/2009/07/direct-ui-by-nokia-maybe-coming-soon/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
On Mon, Sep 7, 2009 at 15:09, Kate Alholakate.alh...@nokia.com wrote: Same thing to Qt, it is not limitation of Qt. App menus looks exactly same rendered with Qt than rendered with GTK. It just uses exactly same style for elements. And this is one of the things which is being asked for! Can you post a simple example (and screenshot) of a Qt program which looks like a normal Maemo 5 app? What's the Qt AppMenu API? Does Qt do more work on behalf of the user (for good or ill) in terms of rotation support? etc. etc. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: New apps for fremantle with Qt?
Hi, On Mon, Sep 7, 2009 at 15:09, Kate Alholakate.alh...@nokia.com wrote: Same thing to Qt, it is not limitation of Qt. App menus looks exactly same rendered with Qt than rendered with GTK. It just uses exactly same style for elements. And this is one of the things which is being asked for! Can you post a simple example (and screenshot) of a Qt program which looks like a normal Maemo 5 app? Off the record: I was just visiting Kate's and Antonio's office and saw application menu demo. Looks nice and works both in landscape and portrait, is themed with the same graphics and looks just like a Maemo 5 Hildon Gtk app. It is coming together nicely. Best Regards, Karoliina ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
fremantle autobuilder maintainer update does not work
Hi, I updated the maintainer in my debian/control file. I send to autobuilder but the new maintainer does not show up in http://maemo.org/packages/view/vncviewer/ By the way, the section update did work. Detlef ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: fremantle autobuilder maintainer update does not work
On Mon, 2009-09-07 at 16:51 +0200, ds wrote: I updated the maintainer in my debian/control file. I send to autobuilder but the new maintainer does not show up in http://maemo.org/packages/view/vncviewer/ I had the same problem. See this message and the replies on tmo: http://talk.maemo.org/showpost.php?p=323042postcount=99 Cheers! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
Hi Andrew, Qt AppMenu API is quite simple, but you don' need it at all. It's just for Qt internal use. To have Maemo5 menus in Qt you don't have to code (at least you can.. but using Qt Designer is better:P) Those menus are filled with the QActions available in the QMainWindows. Basically this the standard way to create menus in Qt (except you don't have to put QActions with menus). QMainWindow will take care of creating and showing the Actions as items of the Qt Maemo5 menu. I've picture in portrait and landscape mode of it.. I'll publish them ASA I've the permission. HildonStackableWindowhttps://git.maemo.org/projects/hildon/gitweb?p=hildon;a=blob;f=hildon/hildon-stackable-window.h;hb=HEADare supported by Qt as well. I implemented them in QMainWindows because it is convenient (they supports the menu). To put them in your app you have to create a QMainWindows parent of another QMainWindow, You don't need nothing more. About the Rotation support..it can be enabled with ONE line. But I'll talk more about it next episode! :P Cheers, Antonio On Mon, Sep 7, 2009 at 5:16 PM, Andrew Flegg and...@bleb.org wrote: On Mon, Sep 7, 2009 at 15:09, Kate Alholakate.alh...@nokia.com wrote: Same thing to Qt, it is not limitation of Qt. App menus looks exactly same rendered with Qt than rendered with GTK. It just uses exactly same style for elements. And this is one of the things which is being asked for! Can you post a simple example (and screenshot) of a Qt program which looks like a normal Maemo 5 app? What's the Qt AppMenu API? Does Qt do more work on behalf of the user (for good or ill) in terms of rotation support? etc. etc. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Joan Crawfordhttp://www.brainyquote.com/quotes/authors/j/joan_crawford.html - I, Joan Crawford, I believe in the dollar. Everything I earn, I spend. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
On Mon, Sep 07, 2009 at 05:09:25PM +0300, Kate Alhola wrote: The importance and the goal of Hildon is to provide a set of essential widgets so a) app developers don't have to waste their time in writing them themselves b) there is UI consistency between all applications If there are no Qt equivalents for all Hildon widgets, none of these two problems are solved, no matter how easy it is for developers to write their own widgets or how compact the code is. If you think that if there is not 1 to 1 equivalent for everything, there is nothing. No, I haven't said that. What I say is: * The Fremantle UI style depends heavily on a set of widgets that have been specifically designed for it. * These include some very fundamental widgets such as HildonAppMenu, HildonPickerButton and HildonStackableWindow. * If you take a look at the N900 you'll see that these widgets are used ALL OVER THE PLACE. * Example: there's no application in the N900 using a menu other than HildonAppMenu. * If you want to use a menu in your application you must use HildonAppMenu or a widget designed to mimic its look and feel, else your application will look different. * There's nothing necessarily wrong with that (e.g. Canola), but developers should be aware before starting to write their apps. So: * Do you want to provide Qt libs for developing Fremantle apps? Good * Are all the widgets that have been designed as a central part of the Fremantle UI available in Qt? Good * Aren't they available yet? Fair enough, but then make sure that developers are aware of this. The bottom line: * Telling people that it's completely reasonable to write Fremantle apps in Qt without making clear that some fundamental Fremantle widgets have not been written yet it not a good idea IMHO. It is also other question that which is more wasting time, writing couple of dozen lines when you can save couple of thousand lines in all application by more compact and efficient code with C++ and Qt. I'm not going to start a C vs C++ debate, but I don't think this is an argument here since there are already C++ bindings for Hildon: http://maemomm.garage.maemo.org/docs_unstable/tutorial/html/sec-TouchSelector.html Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: fremantle autobuilder maintainer update does not work
Thanks a lot. I read the discussion but I do not see, why I should trust anybody to change the package who should not be allowed to change the maintainer:-) Detlef Am Montag, den 07.09.2009, 17:03 +0200 schrieb Cornelius Hald: On Mon, 2009-09-07 at 16:51 +0200, ds wrote: I updated the maintainer in my debian/control file. I send to autobuilder but the new maintainer does not show up in http://maemo.org/packages/view/vncviewer/ I had the same problem. See this message and the replies on tmo: http://talk.maemo.org/showpost.php?p=323042postcount=99 Cheers! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proper Way To Call Browser (Fremantle)
@Daniel: Thank you for the info. The interface appears to be roughly the same as Maemo 4. @Andrew: Don't know about Fremantle, but on Diablo browser --url=* opens a new browser process instead of using the current one (if there is one). @David: I look forward to the one in Python (I program in Python, don't know much C)! -- Best Regards, Brent Chiodo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
ext Alberto Garcia wrote: On Mon, Sep 07, 2009 at 05:09:25PM +0300, Kate Alhola wrote: The importance and the goal of Hildon is to provide a set of essential widgets so a) app developers don't have to waste their time in writing them themselves b) there is UI consistency between all applications If there are no Qt equivalents for all Hildon widgets, none of these two problems are solved, no matter how easy it is for developers to write their own widgets or how compact the code is. If you think that if there is not 1 to 1 equivalent for everything, there is nothing. No, I haven't said that. What I say is: * The Fremantle UI style depends heavily on a set of widgets that have been specifically designed for it. * These include some very fundamental widgets such as HildonAppMenu, HildonPickerButton and HildonStackableWindow. * If you take a look at the N900 you'll see that these widgets are used ALL OVER THE PLACE. * Example: there's no application in the N900 using a menu other than HildonAppMenu. * If you want to use a menu in your application you must use HildonAppMenu or a widget designed to mimic its look and feel, else your application will look different. * There's nothing necessarily wrong with that (e.g. Canola), but developers should be aware before starting to write their apps. I agree that. Antonio just answered, you have HildonAppMenu and StackableWindow functionality in Qt. They look exactly same than Hildon equivalents. I said already that you will soon see also PickerButton functionality. Qt API is different than GTK+, that's clear to everyone. So: * Do you want to provide Qt libs for developing Fremantle apps? Good * Are all the widgets that have been designed as a central part of the Fremantle UI available in Qt? Good * Aren't they available yet? Fair enough, but then make sure that developers are aware of this. Try to understand difference between functionality and widget. In most of cases you don't need any special widgets. You have StackableWindows and AppMenus but you don't need to have separate widgets for this. Let's get back to roots once again. There is two ways to implement UI for mobile. 1- You can make new widgets ( Hildon) 2- You can enhance existing widgets to support mobile usecase (Qt) The model used in Qt makes much easier to port applications because it minimizes needs to modify your application. The bottom line: * Telling people that it's completely reasonable to write Fremantle apps in Qt without making clear that some fundamental Fremantle widgets have not been written yet it not a good idea IMHO. Telling is very good idea, it leaves freedom of choice to developer. I think that telling about choices and their consequences is allways good idea. Maemo Qt is at the moment as Beta whereas Hildon for maemo 5 is about final. That is one argument. The other argument is that Harmatan will be Qt based, S60 will have Qt, Qt is a cross platform toolkit .Qt has QGraphicsView, animation API etc for eye candy, Qt has OpenGL-ES2.0 support, it has webkit ... It is also other question that which is more wasting time, writing couple of dozen lines when you can save couple of thousand lines in all application by more compact and efficient code with C++ and Qt. I'm not going to start a C vs C++ debate, but I don't think this is an argument here since there are already C++ bindings for Hildon: http://maemomm.garage.maemo.org/docs_unstable/tutorial/html/sec-TouchSelector.html It's just not C++ issue, Qt is written from scratch as C++ classes and it just makes many things like writing derived classes much easier. I know the C++ bindings, I was the one pushing maemo to support C++ . Kate ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proper Way To Call Browser (Fremantle)
2009/9/7 Brent Chiodo bchi...@gmail.com:
I look forward to the one in Python (I program in Python, don't know much C)!
It's not the perfect solution, but it works both on Maemo and on the Desktop:
import webbrowser
webbrowser.open_new('http://www.maemo.org/')
See http://docs.python.org/library/webbrowser.html for more information.
HTH
Thomas
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
On Monday 07 September 2009 17:21:45 Alberto Garcia wrote: * The Fremantle UI style depends heavily on a set of widgets that have been specifically designed for it. I really don't want to meddle in GTK-vs-Qt discussions, but this particular segment scares me a bit. This sounds to me like saying coding for Fremantle is a one-shot affair - you have these specially designed widgets, which are there only on Fremantle and who knows what their future will be, even if Kate, Antonio et al put together specific widgets/examples for the Fremantle build of Qt. If there is one thing I'm afraid of it's not designing an UI for mobile use, it's redesigning them for each version of the OS (and the snowballing of ifdefs it brings). Just to clarify - I'm not talking about looks, but specific functionality. * Telling people that it's completely reasonable to write Fremantle apps in Qt without making clear that some fundamental Fremantle widgets have not been written yet it not a good idea IMHO. Sigh, I said I won't comment on this, but... I'm not sure what's the developer's alternative. If I use GTK+, I'll happily keep using it in Fremantle and Harmattan, etc. If I use Qt, I certainly won't switch to GTK+ just for Fremantle no matter how essential some widgets might be. If I don't know either of them, the choice is between 'miss some functionality now' and 'miss some functionality later and from there on' (since GTK+ folks will likely be in the same shoes missing out on more and more of the Qt stuff in Maemo 6 and beyond). So unless one plans on writing something trivial and quitting coding before Maemo 6 hits, there is not exactly much choice - for better or worse, these things are IMHO pretty much on ballistic trajectories now. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: New apps for fremantle with Qt?
On Friday 04 September 2009 18:16:43 kate.alh...@nokia.com wrote: To avoid re-inventing the wheel again we are providing examples how you can do things with Qt. If some thing can be done with dozen lines of Qt code, it just matter of taste, should we provide widget or just example that you can cut-and-paste. The most important thing is that we have all basic widgets like finger scrollable lists etc so that only action needed is to collect them together. It is absolutely NOT a matter of taste! Widgets and examples achieve completely different goals. Examples are good if different applications are expected to work differently (e.g. examples are good for showing how to open a browser window or read a file). Widgets are necessary if different applications are expected to look the same. Widgets are not provided just to reduce the amount of coding the application has to do but to provide a single place to change in order to change the look of all applications, without needing to change the application (or even recompile it)! When porting my applications to Fremantle I have not had to add #ifdef's for all my dialog boxes to cause them to have buttons on the right. Why is that? it is because I used a dialog box widget and the widget has been modified to do that! And maybe some future device will decide the dialog box buttons will need to go at the bottom again (maybe it is portrait oriented, or the fashion changes) -- exactly the same binary will work on that platform and the buttons will be at the bottom. Widgets are extremely important for composites. As important as they are for basics. The more widgets you provide the better the standardisation of the application UI -- no composite widget can be replaced with an example without losing that standardisation at some time in the future when the look needs to change. Note that this doesn't mean that the set of widgets for Qt necessarily needs to be the same as for Hildon. Composite widgets are a simple tradeoff of development time against UI standardisation and the Harmatten team may decide to make that tradeoff differently and choose to implement a different set of widgets. And in different toolkits, different amounts of the required behaviours may be built into some of the underlying widgets directly so there are apparently fewer widgets (but, in fact, the widget behaviour is still there). But we need to remember that each time we choose not to implement some behaviour in the toolkit, but leave it as an example for the application, application behaviour for that function will no longer be standardised. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Diablo Libssl broken in extras-devel
Hi, how can i prevent the autobuilder from using libs from extras-devel? A user reported this: I'm trying to upgrade to the latest version: 0.7.20-meaemo1 but I get the following error: Missing application packages: libssl0.9.8 (= 0.9.8f-5) This is due to the fact that this lib is in extras-devel. Even worse: That lib collides with osso-version-rx44 (or so, i forgot the exact error message). So how do i make the build process ignore that lib or how do i get it completely removed from extras-devel and how can i just rebuild that osm2go version? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
On Mon, Sep 07, 2009 at 08:17:01PM +0200, Attila Csipa wrote: This sounds to me like saying coding for Fremantle is a one-shot affair - you have these specially designed widgets, which are there only on Fremantle and who knows what their future will be That's a very reasonable concern, and one that is shared by many people, including me. Nokia has already announced that they're switching from Gtk to Qt in Harmattan (which has been a confusing move for many users and developers), but I don't know if they plan to keep the same basic widgets and UI style that has been designed for Fremantle or not. If the plan is to keep more or less the same UI style I'd expect a decent, community-supported, release of Gtk/Hildon for Harmattan. If the plan is to redesign the UI all over again then God only knows what's going to happen... :-) * Telling people that it's completely reasonable to write Fremantle apps in Qt without making clear that some fundamental Fremantle widgets have not been written yet it not a good idea IMHO. Sigh, I said I won't comment on this, but... I'm not sure what's the developer's alternative. Since I don't know Nokia's plans for Harmattan, I'm afraid I can't help you much more. It's not that I like the current state of confusion much either, I'm just trying to explain how I see things now and I think that it's up to each developer to decide what to do, but evaluating things first. Many will think that it's OK for them to write applications in Qt, even if they don't have the complete set of Hildon widgets available right now, because that's the future of Maemo. Others will prefer, at least for now, to stick to Gtk/Hildon, which has been much more thoroughly tested in Fremantle, and is the one officially supported and guaranteed to be consistent with the rest of the platform. My opinion? Well, right now Maemo is Fremantle. Harmattan will come in the future but we don't know when. The N900 has been released two years after the N810 so it wouldn't be unreasonable to think that the next device can take two more years. It's quite a lot of time to wait to see what's going to happen. The N900 hasn't even reached the stores yet but what we've seen so far suggests that this is going to be much more successful than any previous Maemo device. So I _personally_ don't think I'm going to worry _that much_ about Harmattan right now. In the end it depends a lot on the application developers' skills and long-term plans for their software. And these are my 2 cents. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[Fremantle] Best Way To Present Settings/Options For Home Plugin
I'm developing a Desktop plugin for Fremantle and have a question about how to present plugin Options/Settings. In Diablo there is the Menu - Applet Settings - interface, but is there anything similar for Fremantle? Thanks. -- Best Regards, Brent Chiodo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo Libssl broken in extras-devel
On Sep 7, 2009, at 21:41, Till Harbaum / Lists wrote: Hi, how can i prevent the autobuilder from using libs from extras-devel? I don't think it does, I think it uses libs from the SDK. Ed and Niels will correct me if I'm wrong. A user reported this: I'm trying to upgrade to the latest version: 0.7.20-meaemo1 but I get the following error: Missing application packages: libssl0.9.8 (= 0.9.8f-5) This is due to the fact that this lib is in extras-devel. I don't understand. The user error says missing application packages, you say is there. Could you be specific? Even worse: That lib collides with osso-version-rx44 (or so, i forgot the exact error message). Hard to diagnose the problem without the error message. So how do i make the build process ignore that lib If the lib is a dependency, you cannot ignore it. or how do i get it completely removed from extras-devel and how can i just rebuild that osm2go version? I can remove a library if it is not being used by others. Try dpkg- buildpackage for building debs. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [Fremantle] Best Way To Present Settings/Options For Home Plugin
On Monday 07 September 2009 22:52:14 Brent Chiodo wrote: I'm developing a Desktop plugin for Fremantle and have a question about how to present plugin Options/Settings. I have just done this for GPE. The documentation in the libhildondesktop Reference Manual (http://maemo.org/api_refs/5.0/beta/libhildondesktop/HDHomePluginItem.html) is quite light (look at the section for HDHomePluginItem). Basically you have to set the settings property to tell the desktop you support settings and then connect to the show-settings signal. The example home applet in maemo-examples doesn't show this, unfortunately. Feel free to look at the code in the GPE homepage applet which may not be ideal but which does work (at least in the scratchbox environment). You can get it by doing: svn export http://projects.linuxtogo.org/svn/gpe/trunk/extra/gpe-summary (projects.linuxtogo.org has been down all day but I hope it will be back soon). Look towards the end of gpesummary.c to see the Fremantle code I have added, which includes invoking the settings dialog. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo Libssl broken in extras-devel
Jeremiah, I haven't checked this out myself but I **think** what Till is seeing is that the autobuilder builds his app with the libssl package from extras-devel and ends up with a versioned dependency on that specific version of libssl. However, the extras-devel version of libssl cannot be installed because it conflicts with a Nokia package (presumably it is one of the libraries Nokia installs and does not allow to be replaced). If this guess is right then the new version of libssl should be removed from extras-devel as it can never be used by anyone. But you might want to check out who uploaded it to see if you can find out why. Graham P.S. The autobuilder certainly does use packages from extras-devel (as well as the SDK) to satisfy dependencies. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo Libssl broken in extras-devel
On Sep 8, 2009, at 24:58, Graham Cobb wrote: Jeremiah, I haven't checked this out myself but I **think** what Till is seeing is that the autobuilder builds his app with the libssl package from extras- devel and ends up with a versioned dependency on that specific version of libssl. However, the extras-devel version of libssl cannot be installed because it conflicts with a Nokia package (presumably it is one of the libraries Nokia installs and does not allow to be replaced). If this guess is right then the new version of libssl should be removed from extras-devel as it can never be used by anyone. But you might want to check out who uploaded it to see if you can find out why. Very interesting. I think you are right because someone asked my yesterday to remove libssl since the version they uploaded ddin't work. I imagine they uploaded libssl again since they need it as a dependency. Ed and Niels: Shouldn't we disallow uploading of packages that are un- installable on the tablet? Graham P.S. The autobuilder certainly does use packages from extras-devel (as well as the SDK) to satisfy dependencies. I stand corrected. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
Graham Cobb wrote: When porting my applications to Fremantle I have not had to add #ifdef's for all my dialog boxes to cause them to have buttons on the right. Why is that? it is because I used a dialog box widget and the widget has been modified to do that! Yes, good example! That's about the _only_ thing that you don't have to change! :-) What about hildon_button_set_theme_size(), that you must call for every button? Ciao, Alberto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
