On Thu, Oct 4, 2012 at 10:21 AM, Mark <mark...@gmail.com> wrote:
> 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
Forget my inheritance stuff. I forgot something about QML for a moment.
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
