Re: Color wheel mockup
Hi A colorwheel would look nice, yes :-) The problem with using it in these devices is that it is not possible to perform fine adjustments directly, and that's why it must be complemented by a way to enter/modify numeric values. There is an interesting disjunctive between selecting a color quickly vs. doing it precisely. Looking at other applications (i.e. GIMP), one sees that there are several acceptable ways of selecting a color, and each one might be better than the others for certain use cases (or even for certain users!). So, I began to wonder if it would be possible to offer several color selectors, maybe through the use of stacked dialogs (horror!) or tabs (more horror!). At the end, I settled for more or less the solution represented in the mockup. There is one fixed area in the right side of the dialog with a button for selecting the selector (yeah!), the current color, its HTML-like representation and a Done button. The left area is used to display the different methods for selecting a color. Tap the selector and you get a set of possible ways for selecting a color, i.e.: - GIMP-like (the one in the mockup) - RGB - CMYK - colorwheel - recent colors - ... The interesting part is that changing the selector doesn't change the currently selected color, so if needed you can combine several strategies until you get the color that you want. Additionally, the selected method should be stored (i.e. in a GConf key) so when you open the color selector again you would be presented with the last selector that you used. The nice thing about this is that despite having several ways for selecting a color, if you find one that suits you well you will only have to set it once :-) Regards, Felipe Cornelius Hald wrote: Hi Felipe, I have created a small mockup of a possible HildonExtrasColorChooserDialog. It uses a view in Edit mode (is that the correct term?) to be able to fit the colorwheel in the screen without making it too small. On the left, there is space for the six last used colors. On the right, the use can adjust the selected color in greater detail, even entering the HTML-equivalent code. I thought about adding a way to select the kind of values to be entered (RGB, CMYK, HSL...). What do you think? thanks for joining the discussion and for providing the mockup :) First, I like that you've not given up on the color wheel. I think it's a nice way of selecting a color. The problems is, that it takes quite some space, so the idea to use the complete window makes a sense here. The problem is, that it seems a bit inconsistent with the rest because most of the time simple dialogs are used. For me personally this is not a big problem, but it might be for others. I think the buttons on the left would not be needed as this dialog would already be the Advanced view of the simple color chooser. If you remove those and save some space on the right, maybe you could fit it into a normal dialog? It will probably get a bit difficult to find the right Advanced dialog. But it's great that we already have choice :) What do other think about this mockup? Conny colorselector.svg.gz Description: GNU Zip compressed data signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
Hi, I have created a small mockup of a possible HildonExtrasColorChooserDialog. It uses a view in Edit mode (is that the correct term?) to be able to fit the colorwheel in the screen without making it too small. On the left, there is space for the six last used colors. On the right, the use can adjust the selected color in greater detail, even entering the HTML-equivalent code. I thought about adding a way to select the kind of values to be entered (RGB, CMYK, HSL...). What do you think? Regards, Felipe Cornelius Hald wrote: Personally I would like to see the following widgets: * HildonExtrasColorButton: A button that looks like a HildonCheckButton, but instead of the check mark it displays the selected color. When clicking this button a HildonExtrasColorChooserDialog is opened. * HildonExtrasColorChooserDialog: A dialog that displays a HildonExtrasColorChooser. * HildonExtrasColorChooser: A widget that lets the user select a color by only using fingers. I'm not yet sure how it should look like, but personally I would like something with three color wheels or touch selectors for red, green and blue. Then next to it a field shows the composed color of those three 'color wheels'. Plus an area where you have, for example, the last 8 used colors. colorwheel.svg.gz Description: GNU Zip compressed data signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon input method: how to write a fullscreen keyboard plugin?
Hi,
the problem is that the plugin is supposed to be a widget because in
previous versions it would be embedded inside the Input Method window
that was placed in the lower part of the screen, but this obviously
won't work well for widgets that are a window themselves. I guess that
you should set the plugin type to HILDON_IM_TYPE_FULLSCREEN and keep an
internal field with the actual window, like this:
void
plugin_enable(HildonIMPlugin *plugin, gboolean init)
{
...
gtk_widget_show_all(GTK_WIDGET(priv-window));
...
}
As for having a fullscreen window, I'm not sure about the restrictions
placed by the window manager, but if regular windows don't work well you
could experiment with a dialog window. You could also remove decoration
on that window for a nicer effect.
Regards,
Felipe
xuxing wrote:
Hi,All
I am trying to write a fullscreen keyboard plugin for Hildon input method.
I tried two ways:
1, Call gtk_window_fullscreen in activate_plugin:
It didn't work.
2, Resize the keyboard window to 800X480 in hildon_im_ui_resize_window.
The related application will exit abnormally.And matchbox wm tells:
matchbox-wm: X error warning (0): BadValue (integer parameter out of
range for operation) (opcode: 12)
Is there any constraint on _NET_WM_WINDOW_TYPE_INPUT window in matchbox wm?
Or should I do something special in fullscreen keyboard plugin?
Any hints will be welcome!
Thanks a lot!
立即试试微软地图新功能，msn互动浏览！ 立刻体验！
http://ditu.live.com/?form=CR
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
signature.asc
Description: OpenPGP digital signature
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: scratchbox ide
Frank Banul wrote: I suppose I should have added that I still compile for OS2006. It appears that ESbox doesn't support Gregale. Can Eclipse be used just for source editing? Yes, it is a very good editor for C/C++. I usually edit code on Eclipse and launch a custom Makefile from a console within Scratchbox when I want to compile, run or upload something. Regards, Felipe signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
