Button component width

[Marco Martin]

On Thursday 04 October 2012, Mark wrote:
> > Maybe you could be more specific, as this it sounds just like a
> > frustrated rant? (Which is understandable, but doesn't help improving
> > anything for you in the future.) Maybe those changes are easy to make,
> > maybe your use case hasn't been considered, or maybe you're doing it
> > wrong? :)
> 
> it's certainly not a rant, but it is something that frustrates me.
> I've had a chat with marco some time ago about those issues in
> question and back then we both where right. It didn't work for my
> usecase (to use it as a tooltip), but to get it working for that it
> had to be redesigned a bit. Something that isn't going to happen in
> KDE 4.x because of BC. Though it might happen for 5.x

here we are talking about a button, not the dialog  (that btw i know that it's 
sizing is buggy and it's kind of architectural, plasma2 material)

the general tone definitely looked like a rant to me and frankly is one of the 
messages that makes me want just unsubscribe from this list

(and no, i won't post further answers to this thread)

> So no, i wasn't doing it wrong :)
> Anyway, back on buttons. In my opinion the plasma qml components
> should just work as simple as the qt desktop components. Don't try to

there is no such thing (yet) as qt desktop components.
there are qwidgets, of which it never was a target to match neither the 
behavior nor the api, in which btw the behavior of the default button size is 
qstyle dependent. the only style i found so far that doesn't use a fixed 
default btw is oxygen (and something thst should be fixed, btw)


> "outsmart" by "giving" him a consistent layout. The developer might
> not want that. I'm just against that idea. Again, i can understand

that's fine, it doesn't have to be agreed by "everybody" because this just 
never happens.

anyways you *can* resize the button, with the review request by david in 
pipeline you *can* resize it to the minimum size, therefore all of this is a 
moot point.

> > soon as you use more than one button, it will easily look "off" and
> > becomes incredibly hard to align. In such cases, I tend to do that
> > alignment "from the outside", but as Marco says, I don't think it's a
> > good idea to require it.
> 
> This is how it should work in my opinion. A designer designs the GUI.
> A developer implements the GUI. That's how it should work in a perfect
> world and in that case the developer decides how the layout looks, not
> the components themselves. However, in the OSS world there is a bit of

this to me seems to prove that even if we would have designers, their opinion 
wouldn't count anything, and is one of the many reasons we don't have many

> So, it is a difficult thing to use. Perhaps we should have a subset of
> components even for the desktop:
> --- NOTE: just brainstorming! --
> // The same as the current org.kde.plasma.components just renamed to
> "Autocomponents" to indicate that they will do things for you.
> import org.kde.plasma.autocomponents 0.1 as PlasmaAutocomponents

I hope the maintainance and inconsistency hell of this is self evident, so 
won't comment further on it.

> If my memory serves me well, the original goal of plasma components
> was to follow the Qt Desktop Components API. Somewhere the plasma
> components seem to have loosen that idea..

nope, never was.
the target was to follow the api of components that are already released, that 
is symbian and meego ones.

qwidget api was never considered because doesn't work that well in a 
declarative language and just has too much legacy.

there is an upstream project for desktop components and is
https://qt.gitorious.org/qtplayground/qtdesktopcomponents

it will again more or less follow the same api, but with several additions 
needed for complicated desktop apps, such as more intelligent layouts
(maybe some incompatibility, hope not too much)

unfortunately is not known when it will be released (*if* will be released, 
even), but that is the one that covers the complex desktop app, *not* the 
plasma components.

the plasma components were primarly designed for the primary use case that 
plasma always had: simple widgets, even on a fairly sandboxed api.

this covers several use cases, that are addons for the desktop shell, and by 
coincidence simple mobile apps, or even simple desktop apps where is 
acceptable an extremely simplified ui that doesn't follow the desktop widget 
style.
The case of addons for the desktop shell is the one that has been used more 
and since many years, way before those qml components. it always has been 
designed to be even more limited than a mobile app and stays so.

the fact that the project for full desktop apps is not ready is unfortunate, 
but still its use case is radically different from the plasma components one.
If you do a complex desktop app, *don't* use plasma components, they were not 
designed for that job, for valid reasons.

you know "if you have an hammer every proplem looks like a nail"

Cheers,
Marco Martin