Re: mouse plugins config

[Ben Cooksley]

On Tue, Nov 24, 2009 at 6:31 PM, Hugo Pereira Da Costa
 wrote:
> On 11/23/2009 10:26 PM, Ben Cooksley wrote:
>> On Tue, Nov 24, 2009 at 9:49 AM, Hugo Pereira Da Costa
>>   wrote:
>>
>>> On 11/23/2009 01:15 PM, Chani wrote:
>>>
>>> On November 22, 2009 21:47:35 Hugo Pereira Da Costa wrote:
>>>
>>>
>>> Hi Chani,
>>> just a naive question, why do you use a "sunken" frame to display the
>>> triggers ? As far as I know this is the only place where things are
>>> presented this way (usually config have either Tabs, group boxes, or are
>>> plain flat). Is there a specific reason here ?
>>>
>>>
>>> it's in a scrollarea. I'll try to get rid of the frame cruft in designer...
>>>
>>>
>>> actually: setting no-frame on a QScrollArea and keeping the background in
>>> sync with the main window is a bit tricky (by default QScrollArea has a flag
>>> background).
>>> The way I did it in my past Qt code was by setting the QScrollArea viewport
>>> manually (because the default ones provided by Qt has some flags that it is
>>> too late for you to change after creation.
>>> Something like:
>>>
>>> QScrollArea* scroll = new QScrollArea();
>>>
>>> scroll->setWidgetResizable ( true );
>>>
>>> scroll->setFrameStyle( QFrame::NoFrame );
>>>
>>> base->layout()->addWidget( scroll );
>>>
>>> QWidget *view_port = new QWidget();
>>>
>>> scroll->setViewport( view_port );
>>>
>>> I don't know how e.g. system-settings do it (in trunk. That was not donne
>>> for kde4.3 and is therefore bugged, for e.g. oxygen ). Maybe they have a
>>> more elegant solution.
>>>
>> I didn't change anything for Trunk with regards to this. In KDE 4.2 it
>> was using a dialog based hack ( but that was changed, first in the
>> original System Settings and then in the new System Settings, which
>> was imported a few weeks later ) but the code that handles that hasn't
>> changed at all between 4.3 and Trunk ( except possibly external
>> application support )
>>
> Hi Ben,
> its a "subtle" bug. See
>
> http://img4.imageshack.us/img4/7923/systemsettings.png

Eww. Never seen that before myself.

>
> (notably the bottom left corner of the stack widget, but also the
> (almost invisible) vertical delimitation just above the tabbar).
>
> Now, I actually think it was more of a Qt issue.
> Might have been fixed in Qt4.6

I can't see it at the moment but that might just be my system.

I'll keep an eye out for this.
Thanks for pointing this out Hugo.

Regards,
Ben.

>> I never recieved any bug reports for it either.
>>
>>
>>>
>>> Unrelated:
>>> is "Trigger" the right word ?
>>> I was thinking that user Joe would consider trigger as ... well ...
>>> something to make your gun shoot. But maybe my english is not good enough.
>>>
>>> Hugo
>>>
>>>
>>>
>>>
>>> ___
>>> Plasma-devel mailing list
>>> Plasma-devel@kde.org
>>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>>
>>>
>>> ___
>>> Plasma-devel mailing list
>>> Plasma-devel@kde.org
>>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>>
>>>
>>>
>> Ben Cooksley
>> System Settings Maintainer
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Hugo Pereira Da Costa]

On 11/23/2009 10:26 PM, Ben Cooksley wrote:
> On Tue, Nov 24, 2009 at 9:49 AM, Hugo Pereira Da Costa
>   wrote:
>
>> On 11/23/2009 01:15 PM, Chani wrote:
>>
>> On November 22, 2009 21:47:35 Hugo Pereira Da Costa wrote:
>>
>>
>> Hi Chani,
>> just a naive question, why do you use a "sunken" frame to display the
>> triggers ? As far as I know this is the only place where things are
>> presented this way (usually config have either Tabs, group boxes, or are
>> plain flat). Is there a specific reason here ?
>>
>>
>> it's in a scrollarea. I'll try to get rid of the frame cruft in designer...
>>
>>
>> actually: setting no-frame on a QScrollArea and keeping the background in
>> sync with the main window is a bit tricky (by default QScrollArea has a flag
>> background).
>> The way I did it in my past Qt code was by setting the QScrollArea viewport
>> manually (because the default ones provided by Qt has some flags that it is
>> too late for you to change after creation.
>> Something like:
>>
>> QScrollArea* scroll = new QScrollArea();
>>
>> scroll->setWidgetResizable ( true );
>>
>> scroll->setFrameStyle( QFrame::NoFrame );
>>
>> base->layout()->addWidget( scroll );
>>
>> QWidget *view_port = new QWidget();
>>
>> scroll->setViewport( view_port );
>>
>> I don't know how e.g. system-settings do it (in trunk. That was not donne
>> for kde4.3 and is therefore bugged, for e.g. oxygen ). Maybe they have a
>> more elegant solution.
>>  
> I didn't change anything for Trunk with regards to this. In KDE 4.2 it
> was using a dialog based hack ( but that was changed, first in the
> original System Settings and then in the new System Settings, which
> was imported a few weeks later ) but the code that handles that hasn't
> changed at all between 4.3 and Trunk ( except possibly external
> application support )
>
Hi Ben,
its a "subtle" bug. See

http://img4.imageshack.us/img4/7923/systemsettings.png

(notably the bottom left corner of the stack widget, but also the 
(almost invisible) vertical delimitation just above the tabbar).

Now, I actually think it was more of a Qt issue.
Might have been fixed in Qt4.6
> I never recieved any bug reports for it either.
>
>
>>
>> Unrelated:
>> is "Trigger" the right word ?
>> I was thinking that user Joe would consider trigger as ... well ...
>> something to make your gun shoot. But maybe my english is not good enough.
>>
>> Hugo
>>
>>
>>
>>
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
>>  
> Ben Cooksley
> System Settings Maintainer
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Ben Cooksley]

On Tue, Nov 24, 2009 at 9:49 AM, Hugo Pereira Da Costa
 wrote:
> On 11/23/2009 01:15 PM, Chani wrote:
>
> On November 22, 2009 21:47:35 Hugo Pereira Da Costa wrote:
>
>
> Hi Chani,
> just a naive question, why do you use a "sunken" frame to display the
> triggers ? As far as I know this is the only place where things are
> presented this way (usually config have either Tabs, group boxes, or are
> plain flat). Is there a specific reason here ?
>
>
> it's in a scrollarea. I'll try to get rid of the frame cruft in designer...
>
>
> actually: setting no-frame on a QScrollArea and keeping the background in
> sync with the main window is a bit tricky (by default QScrollArea has a flag
> background).
> The way I did it in my past Qt code was by setting the QScrollArea viewport
> manually (because the default ones provided by Qt has some flags that it is
> too late for you to change after creation.
> Something like:
>
> QScrollArea* scroll = new QScrollArea();
>
> scroll->setWidgetResizable ( true );
>
> scroll->setFrameStyle( QFrame::NoFrame );
>
> base->layout()->addWidget( scroll );
>
> QWidget *view_port = new QWidget();
>
> scroll->setViewport( view_port );
>
> I don't know how e.g. system-settings do it (in trunk. That was not donne
> for kde4.3 and is therefore bugged, for e.g. oxygen ). Maybe they have a
> more elegant solution.

I didn't change anything for Trunk with regards to this. In KDE 4.2 it
was using a dialog based hack ( but that was changed, first in the
original System Settings and then in the new System Settings, which
was imported a few weeks later ) but the code that handles that hasn't
changed at all between 4.3 and Trunk ( except possibly external
application support )

I never recieved any bug reports for it either.

>
>
> Unrelated:
> is "Trigger" the right word ?
> I was thinking that user Joe would consider trigger as ... well ...
> something to make your gun shoot. But maybe my english is not good enough.
>
> Hugo
>
>
>
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>

Ben Cooksley
System Settings Maintainer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: KDE Observatory (new plasmoid)

[Sandro Andrade]

>>
>> I've tried the SignalPlotter but apparently its time-dependent
>> approach doesn't properly fit the needs in commit history. I need to
>> include data which are sparse in time and that would be harder to
>> achieve. So, I keep using Qwt, cmake module was included, and checked
>> in CMakeLists.txt.
>
> i see; unfortunate since it really won't blend in with the rest of plasma at
> all. perhaps we need a proper graph widget in libplasma at some point. oh well
> ... not the end of the world in this case.

Ok, I can take this task to myself when KDE Observatory is in better shape.

>
>> > * why is "enable transition effects" an option?
>>
>> I've kept this as an option because disabling effects makes view
>> transition faster.
>
> i really don't see the point of this at all. what benefit is there in making
> the view transitions faster? if they are too slow, speed them up, don't offer
> an option.

Removed :)

> iirc, it wasn't on configuration change, it was when new data arrived from the
> online sources

Yes, fixed ! Transitions are re-started only when views are created or removed.

> you should move this into kdeplasma-addons

Moving ...

Sandro
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Chani]

On November 23, 2009 17:15:06 Aaron J. Seigo wrote:
> On November 23, 2009, Chani wrote:
> > 2) when I click the button, the tooltip unshows, right when the user is
> >  likely to need it most. it shows up again if I move the mouse a few
> >  pixels, but is there a way to manually show it?
> 
> hm.. doesn't seem to be, no, which sucks. maybe a label somewhere that is
> created/shown when needed with appropriate text. a little unfortunate.
> 

unfortunate indeed. there's a way to manually show a tooltip, but then I have 
to manually position it, and manually re-show it if the mouse moves in&out of 
the widget.
unless I can fake a mouse move event :P seems like I'm doing a lot of hacky 
event faking lately.

"when needed" is tricky too; it seems like I'd have to have every input button 
emit signals when it starts & stops wanting input, and then have the UI keep a 
count of them and hide the label when there's 0 of them.

this doesn't feel right. I feel like I'm missing something...
I'm gonna go do something else and hope that my subconscious (or someone on 
this list) comes up with an answer. :)

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Aaron J. Seigo]

On November 23, 2009, Chani wrote:
> 2) when I click the button, the tooltip unshows, right when the user is
>  likely to need it most. it shows up again if I move the mouse a few
>  pixels, but is there a way to manually show it?

hm.. doesn't seem to be, no, which sucks. maybe a label somewhere that is 
created/shown when needed with appropriate text. a little unfortunate.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: KDE Observatory (new plasmoid)

[Aaron J. Seigo]

On November 23, 2009, Sandro Andrade wrote:
> > * i see that it uses Qwt in one class. this is likely to diminish both
> > the user base of it as well as it's "plasma-ness". does
> > Plasma::SignalPlotter give you something similar? if not, then a check in
> > the CMakeLists.txt file for Qwt is required
> 
> I've tried the SignalPlotter but apparently its time-dependent
> approach doesn't properly fit the needs in commit history. I need to
> include data which are sparse in time and that would be harder to
> achieve. So, I keep using Qwt, cmake module was included, and checked
> in CMakeLists.txt.

i see; unfortunate since it really won't blend in with the rest of plasma at 
all. perhaps we need a proper graph widget in libplasma at some point. oh well 
... not the end of the world in this case.

> > * why is "enable transition effects" an option?
> 
> I've kept this as an option because disabling effects makes view
> transition faster.

i really don't see the point of this at all. what benefit is there in making 
the view transitions faster? if they are too slow, speed them up, don't offer 
an option.

> > * it seems that whenever the data is updated, the "slide show" starts
> > from the beginning again; it looks a bit odd to have it start all over
> > again. could it simply keep going with the slideshow instead of
> > restarting it?
> 
> That would be harder to implement since changing configurations often
>  implies in views being created or removed, making views tracking a little
>  bit difficult. Anyway, I think configuration operations aren't going to be
>  quite often.

iirc, it wasn't on configuration change, it was when new data arrived from the 
online sources 

> > * it would make the widget much more immediately approachable if there
> > were some project presets shipped, such as ones for kdelibs, kdepim,
> > kdegames, plasma, etc. do you have thoughts on how that would be best
> > achieved?
> 
> Presets were created to almost all KDE main applications. See
> kdeobservatorypresets.cpp. These are loaded at first run, and can be
> removed, edited. New projects can also be added as previously described.

cool...

you should move this into kdeplasma-addons

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Solidrunner moved to kdereview

[Aaron J. Seigo]

On November 23, 2009, Jacopo De Simoi wrote:
> Should I move it to trunk?
> If so, kdebase or kde-plasma-addons?

i think this one belongs in kdebase. it's a basic feature imo.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Add action support to krunner default interface

[Aaron Seigo]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2259/#review3250
---

Ship it!


- Aaron


On 2009-11-21 18:20:59, Jacopo De Simoi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2259/
> ---
> 
> (Updated 2009-11-21 18:20:59)
> 
> 
> Review request for Plasma and Aaron Seigo.
> 
> 
> Summary
> ---
> 
> This patch adds action support to the default interface by adding a button 
> for each one of actionsForMatch given by the runnerManager. 
> Hovering (and focusing) over a button changes the subtext of the item 
> according to the selected action. 
> 
> The logic is all there, it has still some rough edges from the graphical side 
> (e.g. we should make sure that there are not "too many" displayed actions) 
> and focusing with the keyboard is missing (it should be done togheter with 
> the configuration button) but these can be fixed quite easily once it gets 
> committed.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdebase/workspace/krunner/interfaces/default/interface.h 1052428 
>   trunk/KDE/kdebase/workspace/krunner/interfaces/default/interface.cpp 
> 1052428 
>   trunk/KDE/kdebase/workspace/krunner/interfaces/default/resultitem.h 1052428 
>   trunk/KDE/kdebase/workspace/krunner/interfaces/default/resultitem.cpp 
> 1052428 
>   trunk/KDE/kdebase/workspace/krunner/interfaces/default/resultscene.h 
> 1052428 
>   trunk/KDE/kdebase/workspace/krunner/interfaces/default/resultscene.cpp 
> 1052428 
> 
> Diff: http://reviewboard.kde.org/r/2259/diff
> 
> 
> Testing
> ---
> 
> the only runner supporting actions I am aware of is the Devices (solid) 
> runner (in kdereview); tested with that and it works.
> 
> 
> Screenshots
> ---
> 
> Actions for the device runner
>   http://reviewboard.kde.org/r/2259/s/269/
> 
> 
> Thanks,
> 
> Jacopo
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Add action support to krunner default interface

[Aaron Seigo]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2259/#review3249
---

Ship it!


- Aaron


On 2009-11-21 18:20:59, Jacopo De Simoi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2259/
> ---
> 
> (Updated 2009-11-21 18:20:59)
> 
> 
> Review request for Plasma and Aaron Seigo.
> 
> 
> Summary
> ---
> 
> This patch adds action support to the default interface by adding a button 
> for each one of actionsForMatch given by the runnerManager. 
> Hovering (and focusing) over a button changes the subtext of the item 
> according to the selected action. 
> 
> The logic is all there, it has still some rough edges from the graphical side 
> (e.g. we should make sure that there are not "too many" displayed actions) 
> and focusing with the keyboard is missing (it should be done togheter with 
> the configuration button) but these can be fixed quite easily once it gets 
> committed.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdebase/workspace/krunner/interfaces/default/interface.h 1052428 
>   trunk/KDE/kdebase/workspace/krunner/interfaces/default/interface.cpp 
> 1052428 
>   trunk/KDE/kdebase/workspace/krunner/interfaces/default/resultitem.h 1052428 
>   trunk/KDE/kdebase/workspace/krunner/interfaces/default/resultitem.cpp 
> 1052428 
>   trunk/KDE/kdebase/workspace/krunner/interfaces/default/resultscene.h 
> 1052428 
>   trunk/KDE/kdebase/workspace/krunner/interfaces/default/resultscene.cpp 
> 1052428 
> 
> Diff: http://reviewboard.kde.org/r/2259/diff
> 
> 
> Testing
> ---
> 
> the only runner supporting actions I am aware of is the Devices (solid) 
> runner (in kdereview); tested with that and it works.
> 
> 
> Screenshots
> ---
> 
> Actions for the device runner
>   http://reviewboard.kde.org/r/2259/s/269/
> 
> 
> Thanks,
> 
> Jacopo
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Add removeMatch(es) methods to runnerContext

[Aaron Seigo]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2260/#review3248
---

Ship it!


- Aaron


On 2009-11-22 15:32:19, Jacopo De Simoi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2260/
> ---
> 
> (Updated 2009-11-22 15:32:19)
> 
> 
> Review request for Plasma and Aaron Seigo.
> 
> 
> Summary
> ---
> 
> This patch adds removeMatch and removeMatches methods to RunnerContext; these 
> methods are needed to update results in krunner in case the runner knows that 
> something changed and the previously reported results are not valid anymore 
> (e.g. a window listed by the windows runner is closed [this currently leads 
> to a crash] or a device is removed / changed its state (solid runner), a file 
> has been deleted (places runner, nepomuk))
> 
> Both methods fire matchesChanged; in case the match is to be modified the 
> runner can exploit the event compression done by runnermanager by removing 
> the match and adding it back right away with the required modifications. 
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdelibs/plasma/querymatch.h 1052445 
>   trunk/KDE/kdelibs/plasma/querymatch.cpp 1052445 
>   trunk/KDE/kdelibs/plasma/runnercontext.h 1052445 
>   trunk/KDE/kdelibs/plasma/runnercontext.cpp 1052445 
> 
> Diff: http://reviewboard.kde.org/r/2260/diff
> 
> 
> Testing
> ---
> 
> tested (in PoC stage) with the solidrunner and it works
> 
> 
> Thanks,
> 
> Jacopo
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: KDE Observatory (new plasmoid)

[Sandro Andrade]

Hi Aaron,

All suggestions have been done ! See comments below.

Thanks,
Sandro

> * i see that it uses Qwt in one class. this is likely to diminish both the
> user base of it as well as it's "plasma-ness". does Plasma::SignalPlotter give
> you something similar? if not, then a check in the CMakeLists.txt file for Qwt
> is required

I've tried the SignalPlotter but apparently its time-dependent
approach doesn't properly fit the needs in commit history. I need to
include data which are sparse in time and that would be harder to
achieve. So, I keep using Qwt, cmake module was included, and checked
in CMakeLists.txt.

> * the collectors really look like something that would be better as a
> DataEngine. putting data and visualization into one plugin is generally
> frowned upon in plasma. things like the periodic updates of the collectors are
> taken care of for you if you use a DataEngine, other widgets can more easily
> use the results, the data can be shared between multiple instances of the
> kdeobservatory widget and the widget would be more ready for remote widget
> use. perhaps not necessary for 4.4, but should definitely be considered for
> 4.5.

Postponed to 4.5.

> * m_progressProxy should be a Plasma::Meter (i just made some relevant methods
> slots in Plasma::Meter to make that even easier)

Done !

> * collectFinished is probably getting called more often than needed as its
> connected to multiple collectors; that means views and what not will get
> updated for collectors that don't have new data?

Views are updated only when all collectors finish.

> * calling collection[something] as in "if (pair.second &&
> m_viewProviders[view])" will create an entry in the collection if it doesn't
> exist which is probably an unwanted (or at least unneeded) side effect; in
> these cases you probably want m_viewProviders.value(view)

Done !

> * passing in a rect and the code in IViewProvider::createView looks fishy and
> indeed doesn't quite work; when KdeObservator::m_viewContainer changes
> geometry, the views won't change their geometry. i'd suggest either using a
> QGraphicsLayout or else putting an event filter on the view container and
> adjusting the geometry of the views when the view container gets a resize or
> related events.

Done ! Applet was converted to a PopupApplet and all geometry
adjustments are done when resizing events occur.

> * calls like m_right->nativeWidget()->setIcon are generally unecessary. use
> m_right->setIcon() i'd look through all the nativeWidget() calls and see which
> can be removed.

Done !

> * on first update, it sat and spun for the better part of a minute writing to
> disk. subsequent starts up are good. i wonder if this is because each commit
> is added one at a time to the sqllite db instead of several at once? this is a
> show stopper for first use in any case. it also happens when adding more days
> to the context :/

Solved by initiating a transaction before adding commits in database
and committing when everything has finished. There are no delays after
this
change.

> * worse, it blocks the app while doing so. the db should either be updated
> incrementally with regular returns to the mainloop to prevent blocking the
> whole plasma application (e.g. plasma-desktop) or it should be done in a
> thread (probably preferred in this case)

Also solved by previous change. No blocking anymore.

> * the icon button in the Configure KDE Observatory page seems to have some
> layout issues; here it overlaps the divider line at the bottom?

Fixed !

> * sync'ing every minute might be a bit much for the default. 5 or 10 minutes
> should be plenty for a default?

Done !

> * speaking of defaults, is showing just one day of operations really enough to
> give a decent and moral boosting overview? would the last week's worth of data
> be better? a lot of projects see sporadic but regular commits and "one day"
> may not be a whole lot of progress. plasma is active daily as are some of the
> other big projects like kdepim ... but not all are so lucky. this does make
> the db building problem worse, of course.

Default value adjusted to 7 days. Although app blocking doesn't occur
anymore, some time (around 2.5 min) is required for the initial load
of seven-day commits. After that, updates occur very fast.

> * why is "enable transition effects" an option?

I've kept this as an option because disabling effects makes view
transition faster.

> * why are some view options in the global config options and others in the
> Views page?

All view configuration options were grouped in Views configuration page.

> * from a user's perspective, why is there a "global config options"? would
> another name be more useful?

Renamed to "General".

> * the automatic transitions are nice, but when trying to page through them
> with the left/right buttons it really gets in the way. perhaps a "play/pause"
> button could be added to the interface and automatically set it to "pause"
> when one of the ar

Re: mouse plugins config

[Chani]

> 
> does the text at the bottom appear only when one of the trigger buttons is
> pressed? perhaps showing a tooltip on the button in question when it is
> pressed might work nicer (so that one doesn't have to look to the bottom of
> the edit area)?
> 
> perhaps a "Click to change action trigger" tooltip when the button isn't
> pressed, and then show "Press a combination of mouse buttons, scroll
>  wheels, Control, Alt and/or Meta keys that should trigger this action"
>  tooltip when it is pressed?

tried this... not sure if I like it.
1) the tooltip on every unpressed button might get annoying.. and I'll want 
different text on the one at the bottom, which is a bit inconvenient. maybe 
I'll go with no tooltip until it's clicked.
2) when I click the button, the tooltip unshows, right when the user is likely 
to need it most. it shows up again if I move the mouse a few pixels, but is 
there a way to manually show it?

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: About KDE/plasma on small devices

[Alexis Ménard]

On Tue, Nov 24, 2009 at 12:07 AM, Martin Gräßlin
wrote:

> Am Montag 23 November 2009 23:16:10 schrieb Alexis Ménard:
> > KWin works out of the box without anything, it just doesn't have OpenGL
> > support mainly because KWin effects are using raw OpenGL which is
> different
> > from OpenGL ES 2.0. I don't think we need for now to replace the window
> > manager. Matchbox works quite fine.
> Just as a note: I started to work on a shader based implementation for the
> rendering and to get by that KWin ported to OpenGL ES 2.0 and OpenGL 3.
>

awesome!


>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Chani]

On November 23, 2009 12:59:01 Aaron J. Seigo wrote:
> On November 23, 2009, Chani wrote:
> > btw, the column with the config button... it goes all stretchy if there
> > are no plugins with config available. can I fix that with stretch factors
> > too?
> 
> yes :) just setting a stretch factor on the column with the plugin
>  comboboxes should fix both issues.
> 

yep. worked perfectly :)

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Make folderview's hovering popups more usable

[Shafqat Bhuiyan]

> On 2009-11-23 22:15:16, Fredrik Höglund wrote:
> > /trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp, line 1669
> > 
> >
> > Stopping the timer once should hopefully be enough (See the line below 
> > this one).

Whoops. I guess I should of svn up before I started :)


- Shafqat


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2262/#review3246
---


On 2009-11-22 19:56:03, Shafqat Bhuiyan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2262/
> ---
> 
> (Updated 2009-11-22 19:56:03)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch adds two things to make the folderview hovering popups more usable:
> 1. Don't show popup after user clicks on a folder
> 2. Close all popups after user clicks on a file/folder
> 
> Part 1 should be good for all users. However part 2 make takes away 
> multi-file opening. I think this is the correct behavior because this is how 
> most people are accustomed to hovering popup views(eg classic application 
> launchers). Also if a user wants to open multiple files he/she can just open 
> the folder with the files inside.
> 
> This patch isn't too drastic so it may be backported
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp 1052895 
>   /trunk/KDE/kdebase/apps/plasma/applets/folderview/popupview.h 1052895 
>   /trunk/KDE/kdebase/apps/plasma/applets/folderview/popupview.cpp 1052895 
> 
> Diff: http://reviewboard.kde.org/r/2262/diff
> 
> 
> Testing
> ---
> 
> Tested in trunk
> 
> 
> Thanks,
> 
> Shafqat
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: About KDE/plasma on small devices

[Martin Gräßlin]

Am Montag 23 November 2009 23:16:10 schrieb Alexis Ménard:
> KWin works out of the box without anything, it just doesn't have OpenGL
> support mainly because KWin effects are using raw OpenGL which is different
> from OpenGL ES 2.0. I don't think we need for now to replace the window
> manager. Matchbox works quite fine.
Just as a note: I started to work on a shader based implementation for the 
rendering and to get by that KWin ported to OpenGL ES 2.0 and OpenGL 3.


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Solidrunner moved to kdereview

[Jacopo De Simoi]

Should I move it to trunk? 
If so, kdebase or kde-plasma-addons?
Thanks
  --J

On Friday 13 November 2009 19:33:57 Jacopo De Simoi wrote:
> I've just moved a the solidrunner to  kdereview, for inclusion in 4.4 in 
> kde-plasma-addons or kdebase; I'm actually not quite sure on that.
> 
> The runner is conceived as an alternative to the device notifier, combining 
> the same 
> capabilities (although the actions support is still lacking for the default 
> interface in krunner,
> I've already a working draft in local which will soon be posted to the 
> reviewboard) with
> the usual keyboard-oriented way of dealing with stuff which is peculiar to 
> krunner.
> 
> The runner features three syntaxes: 
> 
> device: show all devices 
> mount: show all devices that can be mounted
> unmount: show alll devices that can be unmounted
> 
> Since i believe that people using krunner are more CLI-oriented than the 
> average, the default action is mount/unmount/eject; actions provided by solid 
> actions will are exposed as actions;
> 
> It is also a perfect candidate for the single runner query mode (right now 
> the relevant part has been commented to allow compilation);
> 
> Please let me know of any issues that you find
> Thanks a lot
> 
>   --J
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
> 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: About KDE/plasma on small devices

[Marco Martin]

On Monday 23 November 2009, Alexis Ménard wrote:
> Well i've started the mobile shell, and it's not far... I just come back
> from vacations so i will start again hacking on it.

so be prepared to be horribly harassed, muahahah :D

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: About KDE/plasma on small devices

[Alexis Ménard]

Well i've started the mobile shell, and it's not far... I just come back
from vacations so i will start again hacking on it.

For now, it's just a containment (mainly stole from plasma-desktop and
netbook).

I have implemented an applet to toggle the expose effect in the n900.

The road is long in order to have something usable on the n900. The applet
handle should be redisign, many applets are not finger enabled (though some
of them works quite nice).

And then the main problem is the lack of the documentation in the maemo
side. I had to reverse engineered the dbus server to find out which signal
trigger the expose effect.

On Mon, Nov 23, 2009 at 10:39 PM, Aaron J. Seigo  wrote:

> On November 23, 2009, you wrote:
> > > it's close, but there will be things in it that just don't fit very
> well.
> > > fortunately, plasma encourages a highly modular design and so parts
> that
> > > do make sense can be shared between plasma-netbook and plasma-mobile
> > > without much effort at all.
> > > yes; it could also be something more custom-fitted to a small screen,
> > > particularly when it comes to application transitions. see, for
> instance,
> > >  what the palm pre or even the iphone does in this area.
> >
> > So basically we would need a much more finger friendly smaller/compressed
> > plasma containment.
> > Whih shouldn't be too hard if we would "fork" the netbook maybe?
>
> perhaps; i'd suggest starting with an intended user experience design and
> work
> from there, taking what we can from other places.
>
> > > when it comes to the n900 itself, they use an expose-like effect which
> > >  would mean a different Plasma::View for each widget on the canvas.
> this
> > > is actually not uncommon (it's how popup applets work in the
> > > icon-and-dialog state, e.g. when in a panel in plasma-desktop).
>

I've actually hacked something else, a full screen app...So maemo popups
works well, like when somebody call for instance. Even the compositor do its
job.


> >
> > I would really like to keep the "footprint" as low as possible not just
>

Pointless for now, make things works fine and then you optimize.


> >  from a performance point of view but also from a position that we would
> >  have to port KWin to this special platform which could be worked around
> by
> >  adding the needed pieces upon the ready made plasma right?
>
>
KWin works out of the box without anything, it just doesn't have OpenGL
support mainly because KWin effects are using raw OpenGL which is different
from OpenGL ES 2.0. I don't think we need for now to replace the window
manager. Matchbox works quite fine.


> well, the n900 already provides this out of the box. we don't need to do
> anything there.
>
> there's the additional route of "creating a shell for any phone and do it
> from
> the ground up"; personally, i think we should target the n900 as step 1 and
> then generalize it from there. the reasons are:
>
> * we have n900s to actually run stuff on right now
> * it allows us to grow the project step by step instead of having to do
> everything at once
>
>
Having a plasma-mobile, with couple of useful applets, finger oriented.
Plasma mobile can works in full screen (in addition to the current
hildon-desktop) would be nice for a step 1. Then we can think of creating an
applet for calling and so on.


> > > >  would have the issue that you would get quite scared because most of
> > > > the mobilephone apps would have to be placed there.
> > >
> > > why would this be a problem? I'm not sure i'm seeing the issue here :)
> >
> > From what I've seen on the plasma newspaper the user would either (1)
> need
> >  to always drag the applet upon the newspaper or (2) KEEP all the
> plasmoids
> >  for these phone special stuff upon the newspaper conatinment which makes
> >  it either a hell of a mess or too much to load smooth enough for a daily
> >  workflow.
>
> it again comes back to what user experience plasma-mobile should offer.
>
> one possibility is:
>
> * there is a "home" screen that allows one to put multiple widgets on the
> screen at the same time; basically a tiny version of plasma-desktop's
> desktop
> view
>
>
That is my goal.


> * widgets can also be launched as a "full application", or full screen. in
> that case we create a separate View and show the widget in that view.
>
>
Kate for instance is already running. The problem is Oxygen and the UI, it's
not device enabled. KDE needs lot of work in that side. Plasma is probably
one of the easiest component to have on the N900 because its flexibility.


> the question is if we allow multiple applications to run or just one at a
> time. if just one at a time, then there is just one view and it can
> load/delete widgets on request. lower resource usage, but also slower
> switching between apps. this is the iPhone approach fwiu.


> if multiple, then its up to the user to not launch too many at once,
> closing
> those they don't need/want. perhaps with some automatic management added in

Re: Review Request: Make folderview's hovering popups more usable

[Fredrik Höglund]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2262/#review3246
---

Ship it!


Part 1 is already implemented in SVN, but part 2 looks good to me.


/trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp


Stopping the timer once should hopefully be enough (See the line below this 
one).


- Fredrik


On 2009-11-22 19:56:03, Shafqat Bhuiyan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2262/
> ---
> 
> (Updated 2009-11-22 19:56:03)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch adds two things to make the folderview hovering popups more usable:
> 1. Don't show popup after user clicks on a folder
> 2. Close all popups after user clicks on a file/folder
> 
> Part 1 should be good for all users. However part 2 make takes away 
> multi-file opening. I think this is the correct behavior because this is how 
> most people are accustomed to hovering popup views(eg classic application 
> launchers). Also if a user wants to open multiple files he/she can just open 
> the folder with the files inside.
> 
> This patch isn't too drastic so it may be backported
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp 1052895 
>   /trunk/KDE/kdebase/apps/plasma/applets/folderview/popupview.h 1052895 
>   /trunk/KDE/kdebase/apps/plasma/applets/folderview/popupview.cpp 1052895 
> 
> Diff: http://reviewboard.kde.org/r/2262/diff
> 
> 
> Testing
> ---
> 
> Tested in trunk
> 
> 
> Thanks,
> 
> Shafqat
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: About KDE/plasma on small devices

[Aaron J. Seigo]

On November 23, 2009, you wrote:
> > it's close, but there will be things in it that just don't fit very well.
> > fortunately, plasma encourages a highly modular design and so parts that
> > do make sense can be shared between plasma-netbook and plasma-mobile
> > without much effort at all.
> > yes; it could also be something more custom-fitted to a small screen,
> > particularly when it comes to application transitions. see, for instance,
> >  what the palm pre or even the iphone does in this area.
> 
> So basically we would need a much more finger friendly smaller/compressed
> plasma containment.
> Whih shouldn't be too hard if we would "fork" the netbook maybe?

perhaps; i'd suggest starting with an intended user experience design and work 
from there, taking what we can from other places.

> > when it comes to the n900 itself, they use an expose-like effect which
> >  would mean a different Plasma::View for each widget on the canvas. this
> > is actually not uncommon (it's how popup applets work in the
> > icon-and-dialog state, e.g. when in a panel in plasma-desktop).
> 
> I would really like to keep the "footprint" as low as possible not just
>  from a performance point of view but also from a position that we would
>  have to port KWin to this special platform which could be worked around by
>  adding the needed pieces upon the ready made plasma right?

well, the n900 already provides this out of the box. we don't need to do 
anything there.

there's the additional route of "creating a shell for any phone and do it from 
the ground up"; personally, i think we should target the n900 as step 1 and 
then generalize it from there. the reasons are:

* we have n900s to actually run stuff on right now
* it allows us to grow the project step by step instead of having to do 
everything at once

> > >  would have the issue that you would get quite scared because most of
> > > the mobilephone apps would have to be placed there.
> >
> > why would this be a problem? I'm not sure i'm seeing the issue here :)
> 
> From what I've seen on the plasma newspaper the user would either (1) need
>  to always drag the applet upon the newspaper or (2) KEEP all the plasmoids
>  for these phone special stuff upon the newspaper conatinment which makes
>  it either a hell of a mess or too much to load smooth enough for a daily
>  workflow.

it again comes back to what user experience plasma-mobile should offer.

one possibility is:

* there is a "home" screen that allows one to put multiple widgets on the 
screen at the same time; basically a tiny version of plasma-desktop's desktop 
view

* widgets can also be launched as a "full application", or full screen. in 
that case we create a separate View and show the widget in that view.

the question is if we allow multiple applications to run or just one at a 
time. if just one at a time, then there is just one view and it can 
load/delete widgets on request. lower resource usage, but also slower 
switching between apps. this is the iPhone approach fwiu.

if multiple, then its up to the user to not launch too many at once, closing 
those they don't need/want. perhaps with some automatic management added in as 
well to keep it from getting out of hand.

as for things like the phone dialing pad, contacts .. those could be handled 
separately and created/shown on demand.

> > > So one of the things that would need to be inplace would be information
> > > for people who are not yet involved in the development.  For now  small
> > > wrap up on the mailing list would help to get first pointers upon from
> > > where to tackle all these issues.
> >
> > if you ask questions, we can provide answers :)
> 
> Oki doke. I'll start off . It would be nice if you could give out pointers
>  to the needed  svn repositories etc.

svn.kde.org for the moment, with plasma-mobile in playground/base as i pointed 
out earlier.

>  I haven't come around to do that. To
>  encurage people to join us we should also to document it so others can
>  have a look at it.

agreed; we have a few steps first, particularly defining what user experience 
goal we want to shoot for.

> When we do actually start to write application code for the
> sms/phonecall/contacts apps for the mobile device which actual ibraries
>  should be taken to manage that. Will we pick the freesmartphone libraries
>  or will we pick on the meamo platform and keepit there?

if the telephony features are put into dataengines and services, this becomes 
a non-issue. we can target the n900 or freesmartphone libs and use the same UI 
on each, just by changing which dataengine/service mix is on the device.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.k

Re: About KDE/plasma on small devices

[Marco Martin]

On Monday 23 November 2009, Andreas Marschke wrote:
> > well, pieces will be in 4.4, such as the keyboard. the plasma-mobile
> > shell doesn't have a target date yet, but is at least started.
> 
> I'm very keen on seeing  how you guys  designed  the keyoard in diffrence
>  what I had in my head about it.
> 
> > it's close, but there will be things in it that just don't fit very well.
> > fortunately, plasma encourages a highly modular design and so parts that
> > do make sense can be shared between plasma-netbook and plasma-mobile
> > without much effort at all.
> > yes; it could also be something more custom-fitted to a small screen,
> > particularly when it comes to application transitions. see, for instance,
> >  what the palm pre or even the iphone does in this area.
> 
> So basically we would need a much more finger friendly smaller/compressed
> plasma containment.
> Whih shouldn't be too hard if we would "fork" the netbook maybe?

something to fork, something not,
before doing testing on the real thing on what it works and what it doesn't 
everything is just conjectures i think

> > i really think, given the size of the device, that an emphasis on full
> >  screen apps and switching easily between them with nice visual effects
> >  would be good.
> >
> > when it comes to the n900 itself, they use an expose-like effect which
> >  would mean a different Plasma::View for each widget on the canvas. this
> > is actually not uncommon (it's how popup applets work in the
> > icon-and-dialog state, e.g. when in a panel in plasma-desktop).
> 
> I would really like to keep the "footprint" as low as possible not just
>  from a performance point of view but also from a position that we would
>  have to port KWin to this special platform which could be worked around by
>  adding the needed pieces upon the ready made plasma right?

depends if you want to have the possibility of have any application != plasma 
running on it, if so you need windows.
a kind of task switcher could be done with something similar to the zui.
trascuring for a while the horrid performance of view scaling, not sure is a 
good idea anyways...

> > >  would have the issue that you would get quite scared because most of
> > > the mobilephone apps would have to be placed there.
> >
> > why would this be a problem? I'm not sure i'm seeing the issue here :)
> 
> From what I've seen on the plasma newspaper the user would either (1) need
>  to always drag the applet upon the newspaper or (2) KEEP all the plasmoids
>  for these phone special stuff upon the newspaper conatinment which makes
>  it either a hell of a mess or too much to load smooth enough for a daily
>  workflow.

i think we should have 2 processes: one for the main launcher/ui (maybe the 
most fundamental thing too, the phone dialer itself) one for the 
"applications" (and that a thing i've already started in playground

> > > Another ,  more userfriendly, approach could be to add
> > > containments/activities for sms/phonecalls/videos or what ever somebody
> > >  would want to use there. These would then added dynamically as a new
> > >  Activity you would switch them by providing the
> > > activities-switch-plasmoid in each activities panel. Unfortunately I am
> > > not fully aware about how easy/hard it is to do things like that.
> >
> > creating Containments (which we call "Activities" in the user interface
> >  when they are on the desktop layer in plasma-desktop or the top bar in
> >  plasma- netbook) is trivial: Corona::addContainment. then it's just a
> >  matter of deciding when that should be called.
> >
> > as for creating containments for each ... it might make sense to just
> >  create plasmoids for each and treat them more or less like any other
> >  widget.
> 
> And then "just" Corona::addContainment with this plasmoid in it?
> I would rather see  Morpheuz's plasmoidviewer on steroids there as this is
> would might keep a good flat load there I believe. But this should be
>  better clarified by performance tests.
> 
> > i also wonder how much of the "this is a phone, let's make a phone call"
> > interface could be put behind/inside a DataEngine/Service pair.
> 
> Definitely a good idea for a DataEngine that would (a) hold the calls
>  /contacts and so on.
> 
> > > So one of the things that would need to be inplace would be information
> > > for people who are not yet involved in the development.  For now  small
> > > wrap up on the mailing list would help to get first pointers upon from
> > > where to tackle all these issues.
> >
> > if you ask questions, we can provide answers :)
> 
> Oki doke. I'll start off . It would be nice if you could give out pointers
>  to the needed  svn repositories etc. I haven't come around to do that. To
>  encurage people to join us we should also to document it so others can
>  have a look at it.
> When we do actually start to write application code for the
> sms/phonecall/contacts apps for the mobile device which actual ibraries
>  shou

Re: About KDE/plasma on small devices

[Andreas Marschke]

> well, pieces will be in 4.4, such as the keyboard. the plasma-mobile shell
> doesn't have a target date yet, but is at least started.
I'm very keen on seeing  how you guys  designed  the keyoard in diffrence what 
I had in my head about it.
> it's close, but there will be things in it that just don't fit very well.
> fortunately, plasma encourages a highly modular design and so parts that do
> make sense can be shared between plasma-netbook and plasma-mobile without
>  much effort at all.
> yes; it could also be something more custom-fitted to a small screen,
> particularly when it comes to application transitions. see, for instance,
>  what the palm pre or even the iphone does in this area.

So basically we would need a much more finger friendly smaller/compressed 
plasma containment.
Whih shouldn't be too hard if we would "fork" the netbook maybe?

> i really think, given the size of the device, that an emphasis on full
>  screen apps and switching easily between them with nice visual effects
>  would be good.
 
> when it comes to the n900 itself, they use an expose-like effect which
>  would mean a different Plasma::View for each widget on the canvas. this is
>  actually not uncommon (it's how popup applets work in the icon-and-dialog
>  state, e.g. when in a panel in plasma-desktop).
I would really like to keep the "footprint" as low as possible not just from a 
performance point of view but also from a position that we would have to port 
KWin to this special platform which could be worked around by adding the 
needed pieces upon the ready made plasma right?
 
> >  would have the issue that you would get quite scared because most of the
> >  mobilephone apps would have to be placed there.
> 
> why would this be a problem? I'm not sure i'm seeing the issue here :)
>From what I've seen on the plasma newspaper the user would either (1) need to 
always drag the applet upon the newspaper or (2) KEEP all the plasmoids for 
these phone special stuff upon the newspaper conatinment which makes it either 
a hell of a mess or too much to load smooth enough for a daily workflow.
> > Another ,  more userfriendly, approach could be to add
> > containments/activities for sms/phonecalls/videos or what ever somebody
> >  would want to use there. These would then added dynamically as a new
> >  Activity you would switch them by providing the
> > activities-switch-plasmoid in each activities panel. Unfortunately I am
> > not fully aware about how easy/hard it is to do things like that.
> 
> creating Containments (which we call "Activities" in the user interface
>  when they are on the desktop layer in plasma-desktop or the top bar in
>  plasma- netbook) is trivial: Corona::addContainment. then it's just a
>  matter of deciding when that should be called.
> 
> as for creating containments for each ... it might make sense to just
>  create plasmoids for each and treat them more or less like any other
>  widget.
And then "just" Corona::addContainment with this plasmoid in it? 
I would rather see  Morpheuz's plasmoidviewer on steroids there as this is 
would might keep a good flat load there I believe. But this should be better 
clarified by performance tests. 
> i also wonder how much of the "this is a phone, let's make a phone call"
> interface could be put behind/inside a DataEngine/Service pair.
Definitely a good idea for a DataEngine that would (a) hold the calls /contacts 
and so on. 
> > So one of the things that would need to be inplace would be information
> > for people who are not yet involved in the development.  For now  small
> > wrap up on the mailing list would help to get first pointers upon from
> > where to tackle all these issues.

> if you ask questions, we can provide answers :)
Oki doke. I'll start off . It would be nice if you could give out pointers to 
the needed  svn repositories etc. I haven't come around to do that. To 
encurage people to join us we should also to document it so others can have a 
look at it. 
When we do actually start to write application code for the 
sms/phonecall/contacts apps for the mobile device which actual ibraries should 
be taken to manage that. Will we pick the freesmartphone libraries or will we 
pick on the meamo platform and keepit there?
This is something to be clear about as we would ,unwantedly ,either disclose 
others from helping or bring problems to the distributers as they would have 
to decide how to pick their stack together. 

Cheers,

Andreas Marschke.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Aaron J. Seigo]

On November 23, 2009, Chani wrote:
> btw, the column with the config button... it goes all stretchy if there are
>  no plugins with config available. can I fix that with stretch factors too?

yes :) just setting a stretch factor on the column with the plugin comboboxes 
should fix both issues.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Hugo Pereira Da Costa]

On 11/23/2009 01:15 PM, Chani wrote:

On November 22, 2009 21:47:35 Hugo Pereira Da Costa wrote:
   

Hi Chani,
just a naive question, why do you use a "sunken" frame to display the
triggers ? As far as I know this is the only place where things are
presented this way (usually config have either Tabs, group boxes, or are
plain flat). Is there a specific reason here ?
 

it's in a scrollarea. I'll try to get rid of the frame cruft in designer...
   
actually: setting no-frame on a QScrollArea and keeping the background 
in sync with the main window is a bit tricky (by default QScrollArea has 
a flag background).
The way I did it in my past Qt code was by setting the QScrollArea 
viewport manually (because the default ones provided by Qt has some 
flags that it is too late for you to change after creation.

Something like:

QScrollArea* scroll = new QScrollArea();

scroll->setWidgetResizable ( true );

scroll->setFrameStyle( QFrame::NoFrame );

base->layout()->addWidget( scroll );

QWidget *view_port = new QWidget();

scroll->setViewport( view_port );


I don't know how e.g. system-settings do it (in trunk. That was not 
donne for kde4.3 and is therefore bugged, for e.g. oxygen ). Maybe they 
have a more elegant solution.



Unrelated:
is "Trigger" the right word ?
I was thinking that user Joe would consider trigger as ... well ... 
something to make your gun shoot. But maybe my english is not good enough.


Hugo


   



___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
   


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Draft: Widgets Explorer "Add Widgets"

[Artur Souza (MoRpHeUz)]

Hey!

On Monday 23 November 2009, 15:39 Anselmo Lacerda S. de Melo wrote:
> WIP to make the close button work. A question: Should this button
> close only the widgets explorer (and show the panel settings again) or
> should it close both?

Probably just widgets explorer as it may appear without the panel ? Just 
guessing.

Cheers!

--
Artur Duque de Souza
openBossa
INdT - Instituto Nokia de Tecnologia
--
Blog: http://blog.morpheuz.cc
PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
--


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Aaron J. Seigo]

On November 23, 2009, Chani wrote:
> > > 2. Change actions/edit-delete.png icon to actions/list-remove.png for
> > >  remove button
> >
> > +1
> 
> I don't understand why everyone likes that red dash. I've always thought
>  the red x communicated more clearly that this is a destructive action.

that's up to the artists; the code should use the most fitting icon by name 
...

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Chani]

On November 23, 2009 10:25:19 Aaron J. Seigo wrote:
> On November 22, 2009, Chani wrote:
> > I've rearrranged some things, and added some stuff...
> > http://chani.ca/sshots/mousplugins.png
> 
> some header strings are missing that would make it a bit more obvious imho;
>  or maybe not? :)
> 
> instead of "Mouse Plugins" perhaps "Mouse Actions"?

h.
yes.

> 
> does the text at the bottom appear only when one of the trigger buttons is
> pressed? perhaps showing a tooltip on the button in question when it is
> pressed might work nicer (so that one doesn't have to look to the bottom of
> the edit area)?

right now the text is always there; I was considering showing it only when 
pressed. a tooltip? hmm. depends on the exact behaviour of tooltips perhaps 
(I'll have to go play with them and see)

> 
> perhaps a "Click to change action trigger" tooltip when the button isn't
> pressed, and then show "Press a combination of mouse buttons, scroll
>  wheels, Control, Alt and/or Meta keys that should trigger this action"
>  tooltip when it is pressed?

that could work.
oh, and I keep forgetting, I should go into the input button class and make it 
show which modifiers are held down. feedback++

> 
> perhaps the combobox column should have more stretch added to it as well,
>  so that the trigger buttons aren't quite so large?

hmm. I've never played with stretch... I'll see what it does.
btw, the column with the config button... it goes all stretchy if there are no 
plugins with config available. can I fix that with stretch factors too? 

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Chani]

On November 22, 2009 21:47:35 Hugo Pereira Da Costa wrote:
> Hi Chani,
> just a naive question, why do you use a "sunken" frame to display the
> triggers ? As far as I know this is the only place where things are
> presented this way (usually config have either Tabs, group boxes, or are
> plain flat). Is there a specific reason here ?

it's in a scrollarea. I'll try to get rid of the frame cruft in designer...

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Chani]

On November 23, 2009 06:24:35 Michael Rudolph wrote:
> On Mon, Nov 23, 2009 at 05:39, Chani  wrote:
> > anyways, I'm not happy with the new strings at the bottom there. not
> > happy at all. any suggestions?
> 
> Hi Chani,
> 
> I created a little screencast of the plugin configuration work flow.
> (Mainly because I have never done a screencast before and wanted to
> try it once. Perhaps it can be of use to you.) :-)
> 
> http://vimeo.com/7772639
> 
> As Hans already suggested, the "Add trigger"-button could be placed a
> bit more prominently. I put it on top, but it could sure stay at the
> bottom as well. To get rid of the huge chunk of text at the bottom, I
> broke the work flow up in separate steps. Have a look for yourself, to
> see whether the controls are self explanatory or need a little
> description still. But even if you add little descriptions for each
> step, they could be much shorter and more precise than one large text
> like now. (Assuming you are unhappy because of the amount of text) :-)
> 

broke up the workflow? um, you just added the requirement for an extra 
buttonclick.
I already forget half the time that I have to left-click a trigger before I 
can change it :)

changing "input here" to "press key" doesn't remove the need for explanatory 
text... sadly, it highlights the need for it, because you don't choose a 
*mouse* trigger by simply pressing a *key*.

hiding the text until the add-button is clicked would probably be for the 
best, though.

I'm still left without ideas as to how to improve the explanatory text itself. 
:(

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Chani]

On November 23, 2009 10:17:02 Aaron J. Seigo wrote:
> On November 23, 2009, Hans Chen wrote:
> > Amarok -
> > http://images.maketecheasier.com/2008/12/amarok-dynamic-playlist.jpg
> > Dolphin search -
> > http://2.bp.blogspot.com/_zDPqioLuxns/Sv6j1Y548ZI/AHg/XLSyabEI33w
> >/s 1600-h/searching0.png
> 
> honestly, while i understand why it was done like that in dolphin search
>  (to line up with the '+'), i think putting the remove on the left is
>  incorrect in these cases. 'remove' is neither the useful bit of
>  information on the line nor is it the first thing you consider doing (one
>  first reads what the line means)
> 
> the amarok example is really even more random. the -/+ floats centered
> vertically and not aligned with anything else and while there is a 'x' on
>  the top right, the -/+ icons are on the left.
> 
> imho, those interfaces should be fixed rather than spread the misfeatures
>  to this dialog

agreed.

> 
> > I suggest that you
> > 1. Resize the width of the buttons (configure, about, remove) to be
> > consistent with other dialogs, see "All Effects" in "Desktop Effects"
> >  module for example
> 
> +1, though that may or may not be easy depending on the widget and layout.

*how*?
iirc I had to use a qtoolbutton instead of a qpushbutton to get it to look 
decent without text; I'd *like* a bit more padding around the icon but I dunno 
how to get it without hardcoding sizes (which I will not do).

> 
> > 2. Change actions/edit-delete.png icon to actions/list-remove.png for
> >  remove button
> 
> +1

I don't understand why everyone likes that red dash. I've always thought the 
red x communicated more clearly that this is a destructive action.
I'll change it if you want, though.

> 
> > 3. Move remove buttons to the left-most
> 
> when is "remove" ever left-most?
> 
> > 4. Not sure about this; make "Add Trigger" button fill two cells of the
> > layout, below a remove button and trigger button ("Right-Button" in your
> > screenshoot)
> 
> not sure that'd look so hot ...

with the remove button staying on the left, it's a non-issue :)

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Draft: Widgets Explorer "Add Widgets"

[Anselmo Lacerda S. de Melo]

On Mon, Nov 23, 2009 at 10:26 AM, Petri Damstén  wrote:
> Modified the diff so it puts the Get New Widgets to the filter row:
> http://kotisivu.lumonetti.fi/damu0/misc/we.diff
>
> It also adds close button but It's not working yet:
> http://kotisivu.lumonetti.fi/damu0/images/add-widgets1.png

Great =)

I made a small modification in you patch and uploaded to
http://www.anselmolsm.org/public/we2.diff

WIP to make the close button work. A question: Should this button
close only the widgets explorer (and show the panel settings again) or
should it close both?



Anselmo
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: About KDE/plasma on small devices

[Artur Souza (MoRpHeUz)]

Well, Aaron was fast than me for some answers :P

On Monday 23 November 2009, 14:48 Aaron J. Seigo wrote:
> it's close, but there will be things in it that just don't fit very well.
> fortunately, plasma encourages a highly modular design and so parts that do
> make sense can be shared between plasma-netbook and plasma-mobile without
>  much effort at all.

As aseigo said, it's close but at least my experience show that software 
designed for one hardware usually should not be on a different hardware :). 
That's why we have libplasma: to make it easy to write custom plasma "shells". 
I really don't see the netbook shell "as is" on a phone. Some things will 
probably be used like some of it's concepts, some implementation (as Marco 
already pointed out) and other things, but we really need something for phones.

> yes; it could also be something more custom-fitted to a small screen,
> particularly when it comes to application transitions. see, for instance,
>  what the palm pre or even the iphone does in this area.

Yes, and also really finger friendly.

> i really think, given the size of the device, that an emphasis on full
>  screen apps and switching easily between them with nice visual effects
>  would be good.

+1.

> when it comes to the n900 itself, they use an expose-like effect which
>  would mean a different Plasma::View for each widget on the canvas. this is
>  actually not uncommon (it's how popup applets work in the icon-and-dialog
>  state, e.g. when in a panel in plasma-desktop).

I'm still unsure about this. Talking about the n900 we have a lot of 
applications out there and probably we would need kwin to do this job. I think 
that when we solve the problem of virtual desktops vs activities for the 
desktop we might end up with a really nice idea for phones ;) 

> i also wonder how much of the "this is a phone, let's make a phone call"
> interface could be put behind/inside a DataEngine/Service pair.

Yeah, I've wondering if the phone dialer would be something "desktop-shell" 
related or yet another applicationbut the aspect of being a 
dataengine/service makes me think about being a plasmoid too :) I liked this 
idea :D

> if you ask questions, we can provide answers :)

Exactly. There is even a list maemo related for kde developers. Join that and 
share your ideas with us so we don't duplicate effort on this ;)

Cheers!

--
Artur Duque de Souza
openBossa
INdT - Instituto Nokia de Tecnologia
--
Blog: http://blog.morpheuz.cc
PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
--


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Aaron J. Seigo]

On November 22, 2009, Chani wrote:
> I've rearrranged some things, and added some stuff...
> http://chani.ca/sshots/mousplugins.png

some header strings are missing that would make it a bit more obvious imho; or 
maybe not? :)

instead of "Mouse Plugins" perhaps "Mouse Actions"?

does the text at the bottom appear only when one of the trigger buttons is 
pressed? perhaps showing a tooltip on the button in question when it is 
pressed might work nicer (so that one doesn't have to look to the bottom of 
the edit area)?

perhaps a "Click to change action trigger" tooltip when the button isn't 
pressed, and then show "Press a combination of mouse buttons, scroll wheels, 
Control, Alt and/or Meta keys that should trigger this action" tooltip when it 
is pressed?

perhaps the combobox column should have more stretch added to it as well, so 
that the trigger buttons aren't quite so large?

(the frame should be gotten rid of as well, as Hugo already noted...)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Aaron J. Seigo]

On November 23, 2009, Michael Rudolph wrote:
> As Hans already suggested, the "Add trigger"-button could be placed a
> bit more prominently. I put it on top, but it could sure stay at the
> bottom as well.

if it moves to the top, then the items should appear at the top as well. this 
also would mean that we are optimizing the workflow for adding new triggers. 
this could be good if there are lots of triggers and we fact "scrolling off 
the bottom" issues.

however, i wonder if it might lead some to create new triggers instead of 
replacing existing ones when that's really what they mean/want to do?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Aaron J. Seigo]

On November 23, 2009, Hans Chen wrote:
> Amarok -
> http://images.maketecheasier.com/2008/12/amarok-dynamic-playlist.jpg
> Dolphin search -
> http://2.bp.blogspot.com/_zDPqioLuxns/Sv6j1Y548ZI/AHg/XLSyabEI33w/s
> 1600-h/searching0.png

honestly, while i understand why it was done like that in dolphin search (to 
line up with the '+'), i think putting the remove on the left is incorrect in 
these cases. 'remove' is neither the useful bit of information on the line nor 
is it the first thing you consider doing (one first reads what the line means)

the amarok example is really even more random. the -/+ floats centered 
vertically and not aligned with anything else and while there is a 'x' on the 
top right, the -/+ icons are on the left.

imho, those interfaces should be fixed rather than spread the misfeatures to 
this dialog

> I suggest that you
> 1. Resize the width of the buttons (configure, about, remove) to be
> consistent with other dialogs, see "All Effects" in "Desktop Effects"
>  module for example

+1, though that may or may not be easy depending on the widget and layout.

> 2. Change actions/edit-delete.png icon to actions/list-remove.png for
>  remove button

+1

> 3. Move remove buttons to the left-most

when is "remove" ever left-most?

> 4. Not sure about this; make "Add Trigger" button fill two cells of the
> layout, below a remove button and trigger button ("Right-Button" in your
> screenshoot)

not sure that'd look so hot ...

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: taskmanager library: Manual Sorting Fix

[Aaron Seigo]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1526/#review3243
---



/trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h


won't compile with pedantic due to the extra ';'; should really be in the 
implementation and not the header anyways.



/trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp


the groups in this collection are new'd, but never deleted. looks like a 
memory leak.



/trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp


wrong indent



/trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp


at this point the signals connected to/from the previous currentRootGroup() 
should be disconnected and the new currenRootGroup() should be connected up.

otherwise, things like "group only when full" won't work properly.



/trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp


reload, or reconnect() like the above calls?



/trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp


more readable and consistent with totalSize below as if 
(groupable->isGroupItem())



/trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp


won't compile with pedantic


- Aaron


On 2009-10-19 21:10:07, Christian Mollekopf wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1526/
> ---
> 
> (Updated 2009-10-19 21:10:07)
> 
> 
> Review request for Plasma, Aaron Seigo and Marco Martin.
> 
> 
> Summary
> ---
> 
> this fixes the manual sorting strategy, which is broken atm if the desktop is 
> changed.
> 
> Since the manual sorting strategy relies on AbstractGroupableItem pointer not 
> to change, we cannot remove it from the bookkeeping in case it returns (after 
> a desktop change for instance).
> I don't know if this is acceptable because this results in the item never 
> being removed from the itemList until the groupmanager instance is deleted 
> (lifetime of the applet which created the instance).
> 
> Another option would be to identify tasks and groups by WId, which is a bit 
> more complicated, but if you think it would be better/cleaner, i could supply 
> a patch.
> 
> 
> This addresses bug 200255.
> https://bugs.kde.org/show_bug.cgi?id=200255
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasks.h 1034424 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/applets/tasks/tasks.cpp 1034424 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.h 1034424 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.cpp 1034424 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualsortingstrategy.h
>  1034424 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualsortingstrategy.cpp
>  1034424 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.h 1034424 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp 1034424 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualgroupingstrategy.h
>  1034424 
>   
> /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/manualgroupingstrategy.cpp
>  1034424 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.cpp 
> 1034424 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.h 1034424 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1034424 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.h 
> 1034424 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.cpp 
> 1034424 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h 
> 1034424 
>   /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupingstrategy.h 
> 1034424 
> 
> Diff: http://reviewboard.kde.org/r/1526/diff
> 
> 
> Testing
> ---
> 
> Tried it, works.
> 
> 
> Thanks,
> 
> Christian
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Fix flashlabel color in microblogging plasmoid

[Aaron Seigo]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2264/#review3242
---


funy bug; this should be fixed in libplasma, really, which would make this line 
completely obsolete. will do so now...

- Aaron


On 2009-11-22 20:22:39, Philip Muskovac wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2264/
> ---
> 
> (Updated 2009-11-22 20:22:39)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch corrects the constant black flashlabel text to actually use the 
> plasma theme font color as originally intended. (At least on initialization)
> 
> 
> This addresses bug 215672.
> https://bugs.kde.org/show_bug.cgi?id=215672
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdeplasma-addons/applets/microblog/microblog.cpp 1052921 
> 
> Diff: http://reviewboard.kde.org/r/2264/diff
> 
> 
> Testing
> ---
> 
> Tested against kdeplasma-addons-4.3.2-0ubuntu5 and ubuntu6 in Kubuntu Karmic 
> and Lucid. Still broken in KDE trunk.
> 
> 
> Thanks,
> 
> Philip
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: About KDE/plasma on small devices

[Aaron J. Seigo]

On November 21, 2009, Andreas Marschke wrote:
> I've been tinkering about KDE on smaller devices such s the n900 Aaron
>  luckily informed me about the playground project that is in place and will
>  probably be out on 4.4 (the plasma keyboard as far as I'm aware).

well, pieces will be in 4.4, such as the keyboard. the plasma-mobile shell 
doesn't have a target date yet, but is at least started.
 
> In my humble opinion the best suited for the job is the netbook
>  shell.

it's close, but there will be things in it that just don't fit very well. 
fortunately, plasma encourages a highly modular design and so parts that do 
make sense can be shared between plasma-netbook and plasma-mobile without much 
effort at all.

>  Things that are used on the mobile phone could be developed as a
>  plsmoid which would then just be added to the newspaper containment. This

yes; it could also be something more custom-fitted to a small screen, 
particularly when it comes to application transitions. see, for instance, what 
the palm pre or even the iphone does in this area.

i really think, given the size of the device, that an emphasis on full screen 
apps and switching easily between them with nice visual effects would be good.

when it comes to the n900 itself, they use an expose-like effect which would 
mean a different Plasma::View for each widget on the canvas. this is actually 
not uncommon (it's how popup applets work in the icon-and-dialog state, e.g. 
when in a panel in plasma-desktop).

>  would have the issue that you would get quite scared because most of the
>  mobilephone apps would have to be placed there.

why would this be a problem? I'm not sure i'm seeing the issue here :)

> Another ,  more userfriendly, approach could be to add
> containments/activities for sms/phonecalls/videos or what ever somebody
>  would want to use there. These would then added dynamically as a new
>  Activity you would switch them by providing the activities-switch-plasmoid
>  in each activities panel. Unfortunately I am not fully aware about how
>  easy/hard it is to do things like that.

creating Containments (which we call "Activities" in the user interface when 
they are on the desktop layer in plasma-desktop or the top bar in plasma-
netbook) is trivial: Corona::addContainment. then it's just a matter of 
deciding when that should be called.

as for creating containments for each ... it might make sense to just create 
plasmoids for each and treat them more or less like any other widget.

i also wonder how much of the "this is a phone, let's make a phone call" 
interface could be put behind/inside a DataEngine/Service pair.

> So one of the things that would need to be inplace would be information for
> people who are not yet involved in the development.  For now  small wrap up
>  on the mailing list would help to get first pointers upon from where to
>  tackle all these issues.

if you ask questions, we can provide answers :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Michael Rudolph]

On Mon, Nov 23, 2009 at 05:39, Chani  wrote:
> anyways, I'm not happy with the new strings at the bottom there. not happy at
> all. any suggestions?
>

Hi Chani,

I created a little screencast of the plugin configuration work flow.
(Mainly because I have never done a screencast before and wanted to
try it once. Perhaps it can be of use to you.) :-)

http://vimeo.com/7772639

As Hans already suggested, the "Add trigger"-button could be placed a
bit more prominently. I put it on top, but it could sure stay at the
bottom as well. To get rid of the huge chunk of text at the bottom, I
broke the work flow up in separate steps. Have a look for yourself, to
see whether the controls are self explanatory or need a little
description still. But even if you add little descriptions for each
step, they could be much shorter and more precise than one large text
like now. (Assuming you are unhappy because of the amount of text) :-)

michael
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Draft: Widgets Explorer "Add Widgets"

[Petri Damstén]

On Friday 20 November 2009 22:15:45 Anselmo Melo wrote:
> > On 2009-11-20 19:46:47, Marco Martin wrote:
> > > i still think the button should be between the input field and the
> > > tabbar, to not take even more vertical space
> >
> > Anselmo Melo wrote:
> > Nica. I'll change that and update the screenshot.
> 
> Hm... well, the input field and the tabbar are part of the same widget
>  (filteringwidget). Maybe it's better place it on the left of input field
>  to not mix "filters" with "new widget" stuff. I'm going to the airport
>  right now, I'll try to work on it during the flight =)

Modified the diff so it puts the Get New Widgets to the filter row:
http://kotisivu.lumonetti.fi/damu0/misc/we.diff

It also adds close button but It's not working yet:
http://kotisivu.lumonetti.fi/damu0/images/add-widgets1.png

Petri


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: mouse plugins config

[Hans Chen]

Hi,

Looks good, I like it :). However, I don't like that there're different ways
of displaying this add/remove thingy in KDE, e.g.
Amarok -
http://images.maketecheasier.com/2008/12/amarok-dynamic-playlist.jpg
Dolphin search -
http://2.bp.blogspot.com/_zDPqioLuxns/Sv6j1Y548ZI/AHg/XLSyabEI33w/s1600-h/searching0.png

I suggest that you
1. Resize the width of the buttons (configure, about, remove) to be
consistent with other dialogs, see "All Effects" in "Desktop Effects" module
for example
2. Change actions/edit-delete.png icon to actions/list-remove.png for remove
button
3. Move remove buttons to the left-most
4. Not sure about this; make "Add Trigger" button fill two cells of the
layout, below a remove button and trigger button ("Right-Button" in your
screenshoot)

With best regards,
Hans Chen

On Mon, Nov 23, 2009 at 06:47, Hugo Pereira Da Costa
wrote:

>  Hi Chani,
> just a naive question, why do you use a "sunken" frame to display the
> triggers ? As far as I know this is the only place where things are
> presented this way (usually config have either Tabs, group boxes, or are
> plain flat). Is there a specific reason here ?
>
> so I've been working on my plugin config UI again, based on suggestions from
> aaron. it's not 100% done but it's most of the way there now. :)
>
> I've rearrranged some things, and added some 
> stuff...http://chani.ca/sshots/mousplugins.png
> in retrospect, using reviewboard might've been a good idea.
> anyways, I'm not happy with the new strings at the bottom there. not happy at
> all. any suggestions?
>
> oh yeah, and remember, string (and feature) freeze is wednesday. :)
>
>
>
>
> ___
> Plasma-devel mailing 
> listplasma-de...@kde.orghttps://mail.kde.org/mailman/listinfo/plasma-devel
>
>
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel