This is a quick note to say that I updated the mockups a little while ago:
https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements-2.png
These are intended to be a bit simpler than the previous iteration
(found at [1]). I would personally
On 27/12/14 13:02, Matthias Clasen wrote:
over Christmas, I had some for a little side project, a new combo
box. It is based on these mockups:
https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements.png
It looks nice! I've had a look at
Timm Bäder m...@baedert.org wrote:
...
Seems like these mockups (and the new combo box) should be kept in sync
with general popover menus, especially wrt. the grouping behavior (i.e.
separate pages in a GtkStack VS. expanding the new group downwards). I
know Allan favored the latter (and
Alberto Ruiz ar...@gnome.org wrote:
My main concern with the design is that users can't make a difference
between a normal button and this widget (usually related to an action,
perhaps with the exception of iconized menus like the ones we're using in
headerbars these days).
Is there any
Jasper St. Pierre jstpie...@mecheye.net wrote:
So let me ask a very basic question here, since I feel it's at the heart of
the dumb internet argument we're having.
What is this design trying to solve? What problems with the old ComboBox are
we trying to fix? What use cases is it designed for?
On Sun, Dec 28, 2014 at 7:42 PM, Emmanuele Bassi eba...@gmail.com wrote:
just a bunch of comments going through the commits.
Thanks for this!
[...]
as for the overall naming: I think combo box does not entirely
apply, given that the entry is not only optional, but also part of the
drop
On Tue, Dec 30, 2014 at 2:26 AM, Philip Chimento philip.chime...@gmail.com
wrote:
Assuming that questions on Stack Overflow are an approximate poll of what
application authors do - many application authors go to the documentation
and do exactly that. (And often don't bother to read any further
On Sun, 2014-12-28 at 12:53 -0500, Matthias Clasen wrote:
I am a bit disappointed by the turn this discussion has taken - I was
hoping people would try the code I pointed to and let me know what
they think and point out problems (thanks to Tim for doing just that).
Instead, I get arguments
On Sun, Dec 28, 2014 at 9:24 PM, Cosimo Cecchi cosi...@gnome.org wrote:
On Mon, Dec 29, 2014 at 1:09 AM, Jasper St. Pierre jstpie...@mecheye.net
wrote:
Cosimo talks about GtkPopover and GtkMenu, but those just sort of have me
stunned. Why should I use one instead of the other?
I doubt
On 27 Dec 2014, at 18:05, Sébastien Wilmet swil...@gnome.org wrote:
On Sun, Dec 28, 2014 at 12:50:24AM +0900, Tristan Van Berkom wrote:
In any case, I think this misses the point I was trying to make, I think
someone had to raise the obvious question: is it justified to bring in a
whole
On Sun, Dec 28, 2014 at 1:27 AM, Alberto Ruiz ar...@gnome.org wrote:
My main concern with the design is that users can't make a difference
between a normal button and this widget (usually related to an action,
perhaps with the exception of iconized menus like the ones we're using in
headerbars
This is the third (fourth) incarnation of a combo box and there is
still opposition to keeping the API stable? That's just crazy.
Matthias' awesomeness aside, why would this be the last time?
Seriously, a change in a widget like this means 20+ hours[*] of
extra work for me as an application
On 28 December 2014 at 16:32, Morten Welinder mort...@gnome.org wrote:
This is the third (fourth) incarnation of a combo box and there is
still opposition to keeping the API stable? That's just crazy.
on the contrary: with a new class you'd be sure that the GtkComboBox
widget API is finally
So let me ask a very basic question here, since I feel it's at the heart of
the dumb internet argument we're having.
What is this design trying to solve? What problems with the old ComboBox
are we trying to fix? What use cases is it designed for?
Is it the usability problems? Are we adding the
on the contrary: with a new class you'd be sure that the GtkComboBox
widget API is finally stable — as in no changes, except for bug
fixes — which is apparently what you want.
There are three types of widgets in the gtk+ world: (1) active and
non-deprecated, (2) deprecated, and (3) deprecated
hi;
On 28 December 2014 at 17:23, Morten Welinder mort...@gnome.org wrote:
on the contrary: with a new class you'd be sure that the GtkComboBox
widget API is finally stable — as in no changes, except for bug
fixes — which is apparently what you want.
There are three types of widgets in the
I am a bit disappointed by the turn this discussion has taken - I was
hoping people would try the code I pointed to and let me know what
they think and point out problems (thanks to Tim for doing just that).
Instead, I get arguments about how much my time is worth compared to
Mortens, complaints
hi Matthias;
On 27 December 2014 at 13:02, Matthias Clasen matthias.cla...@gmail.com wrote:
over Christmas, I had some for a little side project, a new combo
box. It is based on these mockups:
On Mon, Dec 29, 2014 at 1:53 AM, Matthias Clasen matthias.cla...@gmail.com
wrote:
I am a bit disappointed by the turn this discussion has taken - I was
hoping people would try the code I pointed to and let me know what
they think and point out problems (thanks to Tim for doing just that).
On Mon, Dec 29, 2014 at 1:09 AM, Jasper St. Pierre jstpie...@mecheye.net
wrote:
Cosimo talks about GtkPopover and GtkMenu, but those just sort of have me
stunned. Why should I use one instead of the other?
I doubt application authors choose which widget to use by reading type
names in API
On 27.12, Matthias Clasen wrote:
Hi,
over Christmas, I had some for a little side project, a new combo
box. It is based on these mockups:
https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements.png
Seems like these mockups (and the new
On Sat, Dec 27, 2014 at 10:52:27PM +0900, Tristan Van Berkom wrote:
From a quick look at gtkcombobox.h, the only really problematic part
is the tabular menu nonsense (set_wrap_width(), set_row_span_column(),
set_column_span_column()). Is there any way we could get around that ?
perhaps just an
On Sat, Dec 27, 2014 at 08:02:44AM -0500, Matthias Clasen wrote:
over Christmas, I had some for a little side project, a new combo
box. It is based on these mockups:
https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements.png
...
I'm
Does it work as depicted with Tiling Window Managers?
On Sat, 27 Dec 2014 08:02:44 -0500
Matthias Clasen matthias.cla...@gmail.com wrote:
Hi,
over Christmas, I had some for a little side project, a new combo
box. It is based on these mockups:
On Sun, Dec 28, 2014 at 12:50:24AM +0900, Tristan Van Berkom wrote:
In any case, I think this misses the point I was trying to make, I think
someone had to raise the obvious question: is it justified to bring in a
whole new combo API ? Or can we / should we get the most out of the API
we have
On Sat, 2014-12-27 at 18:05 +0100, Sébastien Wilmet wrote:
On Sun, Dec 28, 2014 at 12:50:24AM +0900, Tristan Van Berkom wrote:
In any case, I think this misses the point I was trying to make, I think
someone had to raise the obvious question: is it justified to bring in a
whole new combo
On 12/27/2014 07:50 AM, Tristan Van Berkom wrote:
In any case, I think this misses the point I was trying to make, I think
someone had to raise the obvious question: is it justified to bring in a
whole new combo API ? Or can we / should we get the most out of the API
we have ?
Can I style
On Sat, 2014-12-27 at 11:44 -0800, Christian Hergert wrote:
On 12/27/2014 07:50 AM, Tristan Van Berkom wrote:
In any case, I think this misses the point I was trying to make, I think
someone had to raise the obvious question: is it justified to bring in a
whole new combo API ? Or can we /
On Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom
tris...@upstairslabs.com wrote:
It's really not that bad, combobox is currently 6k lines of code which
is really not much for all that it does, sure we could afford to do a
bit less (like dropping the crazy tabular menus).
Tbh, thats only
Can we keep the api -- function names, etc.?
I.e., could we, for once, do such an upgrade without inflicting
pain on the users? Even at the cost of some pain for
developers.
Morten
On Sat, Dec 27, 2014 at 4:29 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
On Sat, Dec 27, 2014 at 12:59
On 12/27/2014 01:44 PM, Morten Welinder wrote:
Can we keep the api -- function names, etc.?
I.e., could we, for once, do such an upgrade without inflicting
pain on the users? Even at the cost of some pain for
developers.
On the other hand, this is the type of thing where people also
Thanks, Matthias for working on this, it looks great!
It's pretty clear to me that this widget is different enough from the
current combobox that using the old API and pushing the new design on every
current client is not a good idea - in the same way that GtkPopover was
made a different widget
My main concern with the design is that users can't make a difference
between a normal button and this widget (usually related to an action,
perhaps with the exception of iconized menus like the ones we're using in
headerbars these days).
Is there any design rationale to remove the usual arrow?
On Sat, 2014-12-27 at 16:29 -0500, Matthias Clasen wrote:
On Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom
tris...@upstairslabs.com wrote:
It's really not that bad, combobox is currently 6k lines of code which
is really not much for all that it does, sure we could afford to do a
34 matches
Mail list logo