On Wed, Oct 3, 2012 at 11:39 PM, Sebastian Kügler <se...@kde.org> wrote:
> On Wednesday, October 03, 2012 22:44:20 Mark wrote:
>> You really seem to be thinking in plasma active. And in there it might
>> actually work and benefit in every possible way. On the desktop things
>> like this just don't work. Devs want to have freedom and certainly
>> don't want to be limited. One example is the horror i experienced when
>> using the dialog element for things "slightly" different then it's
>> intended use in which case it becomes completely useless. That
>> component would have been perfect for my needs if it had a little more
>> flexibility.
>
> 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
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
"outsmart" by "giving" him a consistent layout. The developer might
not want that. I'm just against that idea. Again, i can understand
it's usecase for non desktop form factors, just not for the desktop.
But wasn't the beauty of the plasma desktop components that there
could be different implementations for each component depending on the
form factor? Use that awesome capability!
>> Also, setting a minimal size in characters.. Is there any other
>> toolkit out there that's doing that? Again, i can imagine this to work
>> wonderful for plasma active, but it just doesn't work on the desktop.
>> The default width should be calculated based on the string that's put
>> into it. Then devs can decide to ignore that "suggestion" and just set
>> a width of their liking.
>
> I don't think it has much to do with Plasma Active or not. It's a hard problem
> though, sacrifice visual consistency for odd text layout? I tend to lean on
> the "fairly fixed" default button size, simply because as 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
a snatch. Quite often there is no "designer" step and the developer
just "designs" as it progresses. Some developers have an eye for
design details so they will still end up with good looking interfaces.
In those cases the devs should have full control over the components
and the components shouldn't make assumptions of their own to "make it
better looking". Most developers however don't have an eye for design
and end up with a "less optimal" UI for whatever reason and in those
cases a UI that helps them making it look nice will indeed work for
the better part.
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
// Open components that leave the developer open to whatever they want
to do with the components. Those components won't make assumptions and
work just like the Qt desktop components.
import org.kde.plasma.opencomponents 0.1 as PlasmaOpencomponents
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..
What would be really nice to have right now is some kind of QML
Component inheriting.. Kinda like this:
ButtonBase
{
... base button implementation
}
// in PlasmaAutocomponents
Button inherits ButtonBase
{
... button specifics for PlasmaAutocomponents
}
// in PlasmaOpencomponents
Button inherits ButtonBase
{
... button specifics for PlasmaOpencomponents
}
I think i'm drifting off topic :p
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
