User:Frederik/ghns todo: Difference between revisions
| Line 89: | Line 89: | ||
Set background color by using <span style="background:#00FF00"> TEXT </span> | Set background color by using <span style="background:#00FF00"> TEXT </span> | ||
Set both by using <span style="color:#FFFFFF; background:#FF69B4"> TEXT </span> | Set both by using <span style="color:#FFFFFF; background:#FF69B4"> TEXT </span> | ||
= KNewStuff2 Internal Design and problems = | |||
KNewStuff2 currently (as of kde 4.3 and earlier) has a couple of problems that prevent it from easily moving forward to support more interesting features such as server-side searching, and make simple things like knowing what needs to be updated of the installed data tricky also. Here are some things wrong with the design that we will address for 4.4 below. | |||
== Entry ownership == | |||
Currently Entries are owned by Feeds, but in reality, Entries should be owned by the provider that provides them, feeds are just a way of getting a list from the provider (but there will soon be other ways in addition to feeds, search, find all wallpapers uploaded by foo, etc.) | |||
In order to fix this problem Entries will be owned by the Provider they come from (which also means when the registry is loaded, the Entries in there need to be parented by the correct provider, what if the provider is no longer available? A LocalRegistry provider may need to be implemented also?) | |||
<br> | |||
Frederik:<br>Some of this is fixed - entries are managed by providers now.<br>So far, entries have no real parent, but are passed around as shared data objects. It might be a good idea to let entries have a pointer to their owning provider which would make some things easier.<br>Feeds are only used internally by the static xml provider (aka the old stuff), while the new OpenCollaborationService provider, nicknamed Attica, like the lib used to access it, has no such concept. | |||
I'm currently starting to like the idea of the registry provider more and more. | |||
Right now, all caching is disabled. I doubt, that it ever really worked though.<br> | |||
== Engine cruft == | |||
Currently there are Three *Engine classes in KNewStuff2. This complicates things beyond necessity. What's more the inheritance relationship between the Engine classes is odd and not very intuitive. This makes maintaining KNewStuff2 tricky, and also makes it harder for new blood to get involved in bug fixing and adding features. | |||
In order to fix this problem all Engine classes should be combined into one Engine class. It handles the Engine-type stuff (reading local registry? creating provider objects, parsing the knsrc file, etc.). The Engine class leaves most of the server interaction functionality to the Provider class(es) however, and only steps in to do actual work after data has been downloaded and needs to be Installed, or whatnot. This way the provider(s) can be customized to work with each server-side api specifically, and well. | |||
Frederik: this is mostly done. Cache and registry need cleanup, the engine is still a huge clunky thing. Some of the stuff has been moved to a class Installation, which takes care of all the downloading and installing stuff. | |||
== Provider Support == | |||
Currently there are 3 types of providers for GHNS data. Each work fairly well with the current implementation, however HotStuff (what's on newstuff.kde.org) and Open Desktop (what's on kde-look.org, etc.) both have added collaboration functionality that's not currently exposed in the KNewStuff2 gui. This is partly because the two server-side implementations do things a bit differently, but also partly because of trickiness in implementing support for two server-side implementations in unclear engine class heirarchy. | |||
In order to work with this situation well, the creation of a few new Provider classes is to be considered. | |||
A base implementation will provide support for getting Static Website providers (stuff that's hosted in static xml files such as edu.kde.org/newstuff if anyone is still using that). This base implementation could be created by extending the existing KNewStuff2 Provider class. | |||
A sub class DXSProvider class can be implemented that talks to dxs server-side providers. This class would have derived methods to get Comments for an entry, leave comments for an entry, upload, rate, and generally interact with HotStuff implementations. | |||
Another sub class RESTProvider could be implemented also that does likewise for REST server-side implementations. Likewise having methods for getting comments, leaving comments, rating entries, but also for server-side searching (which the DXS Provider can implement once that works in HotStuff, maybe it already does?), paging (show me page 2 of my search, ok, now page 7... etc.), filtering (show me all entries uploaded by coolartist for example). | |||
In order for RESTProvider to provide this added functionality, virtual methods will be added to the base Provider class to get and send this data, and they will do nothing and/or show a message box saying "this provider does not support rating" or somesuch. | |||
= User Interface = | |||
== Providers combobox can go away == | |||
Users don't really care where the data is coming from, and it's much nicer to see all providers data in one view (no apps currently fetch from more than one provider either). So the provider combobox can and should be removed, and all similar data from different providers can be merged together into one view (i.e. all highest rated from kde-look.org and all highest rated from newstuff.kde.org can be in one "Highest Rated" tab) | |||
Done. What needs to be done now is to implement sorting in the sortfilterproxy of the downloaddialog. | |||
== Go back to tabs? == | |||
One problem with the existing ui is that it doesn't give room for server-side search to open new views (it could and just put them in the sort combobox, but sort is not really what that combobox does anyway). It is suggested that we move to tabs like these were in kde 3.x days, and create new tabs for each server-side search (closable tabs of course). | |||
Frederik: I'm totally against this. In the branch I currently have a version working where all searches are done by the providers (in case of staticxml it's just filtering). I find this working well and a lot less confusing than tabs. | |||
== Preview too small == | |||
Another problem with the ui is that the previews are very small and hard to see detail when they are generated from a larger image anyway. Something that has been frequently asked for is the ability to click on the small preview and see a larger one temporarily. This would help users see much easier what visual data they are actually downloading. | |||
Revision as of 17:01, 23 March 2010
my private scratchpad for knewstuff3
Uploaddialog
updating of contentnach erfolgreichem upload link auf website anzeigen (hinweis: deleting of content -> link to website)- wenn edit: link bekannt
wenn add: content/get auf id
währungmittels user/balance
dateiauswahl, wenn keine datei vorgegebensupport 3 screenshotsimage frames super ugly
- fetch previously uploaded images when updating
- going back: fills in the update information again when going to details page 1
- disable update radio as long as no old item has been found
Downloaddialog
link username in ghns dialog to profile page- in general list
in details page- in details page: if no link, add email like in delegate
- FRANK: content/get has no <profilepage> tag
click on image should show detailschangelog and summary in details dialog, scrollbar if neededmake downloaddialog available as widgetbig refactoring of dialog class use Q_PRIVATE_SLOT in the widget, dialog is an empty shell around the widget now
when loading dialog: show progress bar with 0% instead of not showing itinstead us kpixmapsequence
support 3 screenshots- make details screenshot selection less ugly
upload button in download dialog- only enable if it has an attica provider
- support for all downloads (multiple downloadlinks - eg Buildservice)
- toolbutton for install button (drop down, the way it was waaay back then)
- donation button (link to website? api - need to look into what's possible)
- needs server side support for this (at least a link)
- maybe like payment?
- show fans
number of fans in general listFRANK: needed from server in content/list
- actually show fans on details page (ui?)
- if all else fails, link to website
- also show knowledgebase link in details?
- Comments (needs server side api, attica extensions)
- hint: use the plasma widget "news" to get notifications about updates (put into download dialog?)
- when user closes dialog - ask confirmation to cancel running downloads
- bug: translated text too long for buttons
- provider selection in dialog (currently hidden combo box)
refactor engine class to not have a private class and clean up in there- check if the installed files still exist when starting, otherwise offer to install again (?)
- redo layout again? combo boxes on top?
Create class to check for updates automagically
- enable update notification in apps
other
- extended attributes (+parley as showcase)
- rename opendesktop plasmoids
- personal news feed
- community
- kcm provider configuration
- stand alone download app
- book reader
- audio store
- app installer?
- buildservice integration?
- kde-obs-generator
- osc
other 2
Long term: consider notifications from website/dialog/fan - what should go where etc ...
workflow document? how do you think apps should be created - from source to git to obs to opendesktop.org
other 3
reminder how to do colors in wiki: Set text color by using TEXT Set background color by using TEXT Set both by using TEXT
KNewStuff2 Internal Design and problems
KNewStuff2 currently (as of kde 4.3 and earlier) has a couple of problems that prevent it from easily moving forward to support more interesting features such as server-side searching, and make simple things like knowing what needs to be updated of the installed data tricky also. Here are some things wrong with the design that we will address for 4.4 below.
Entry ownership
Currently Entries are owned by Feeds, but in reality, Entries should be owned by the provider that provides them, feeds are just a way of getting a list from the provider (but there will soon be other ways in addition to feeds, search, find all wallpapers uploaded by foo, etc.)
In order to fix this problem Entries will be owned by the Provider they come from (which also means when the registry is loaded, the Entries in there need to be parented by the correct provider, what if the provider is no longer available? A LocalRegistry provider may need to be implemented also?)
Frederik:
Some of this is fixed - entries are managed by providers now.
So far, entries have no real parent, but are passed around as shared data objects. It might be a good idea to let entries have a pointer to their owning provider which would make some things easier.
Feeds are only used internally by the static xml provider (aka the old stuff), while the new OpenCollaborationService provider, nicknamed Attica, like the lib used to access it, has no such concept.
I'm currently starting to like the idea of the registry provider more and more.
Right now, all caching is disabled. I doubt, that it ever really worked though.
Engine cruft
Currently there are Three *Engine classes in KNewStuff2. This complicates things beyond necessity. What's more the inheritance relationship between the Engine classes is odd and not very intuitive. This makes maintaining KNewStuff2 tricky, and also makes it harder for new blood to get involved in bug fixing and adding features.
In order to fix this problem all Engine classes should be combined into one Engine class. It handles the Engine-type stuff (reading local registry? creating provider objects, parsing the knsrc file, etc.). The Engine class leaves most of the server interaction functionality to the Provider class(es) however, and only steps in to do actual work after data has been downloaded and needs to be Installed, or whatnot. This way the provider(s) can be customized to work with each server-side api specifically, and well.
Frederik: this is mostly done. Cache and registry need cleanup, the engine is still a huge clunky thing. Some of the stuff has been moved to a class Installation, which takes care of all the downloading and installing stuff.
Provider Support
Currently there are 3 types of providers for GHNS data. Each work fairly well with the current implementation, however HotStuff (what's on newstuff.kde.org) and Open Desktop (what's on kde-look.org, etc.) both have added collaboration functionality that's not currently exposed in the KNewStuff2 gui. This is partly because the two server-side implementations do things a bit differently, but also partly because of trickiness in implementing support for two server-side implementations in unclear engine class heirarchy.
In order to work with this situation well, the creation of a few new Provider classes is to be considered.
A base implementation will provide support for getting Static Website providers (stuff that's hosted in static xml files such as edu.kde.org/newstuff if anyone is still using that). This base implementation could be created by extending the existing KNewStuff2 Provider class.
A sub class DXSProvider class can be implemented that talks to dxs server-side providers. This class would have derived methods to get Comments for an entry, leave comments for an entry, upload, rate, and generally interact with HotStuff implementations.
Another sub class RESTProvider could be implemented also that does likewise for REST server-side implementations. Likewise having methods for getting comments, leaving comments, rating entries, but also for server-side searching (which the DXS Provider can implement once that works in HotStuff, maybe it already does?), paging (show me page 2 of my search, ok, now page 7... etc.), filtering (show me all entries uploaded by coolartist for example).
In order for RESTProvider to provide this added functionality, virtual methods will be added to the base Provider class to get and send this data, and they will do nothing and/or show a message box saying "this provider does not support rating" or somesuch.
User Interface
Providers combobox can go away
Users don't really care where the data is coming from, and it's much nicer to see all providers data in one view (no apps currently fetch from more than one provider either). So the provider combobox can and should be removed, and all similar data from different providers can be merged together into one view (i.e. all highest rated from kde-look.org and all highest rated from newstuff.kde.org can be in one "Highest Rated" tab)
Done. What needs to be done now is to implement sorting in the sortfilterproxy of the downloaddialog.
Go back to tabs?
One problem with the existing ui is that it doesn't give room for server-side search to open new views (it could and just put them in the sort combobox, but sort is not really what that combobox does anyway). It is suggested that we move to tabs like these were in kde 3.x days, and create new tabs for each server-side search (closable tabs of course).
Frederik: I'm totally against this. In the branch I currently have a version working where all searches are done by the providers (in case of staticxml it's just filtering). I find this working well and a lot less confusing than tabs.
Preview too small
Another problem with the ui is that the previews are very small and hard to see detail when they are generated from a larger image anyway. Something that has been frequently asked for is the ability to click on the small preview and see a larger one temporarily. This would help users see much easier what visual data they are actually downloading.