How Plasma/Kickoff app launcher always opening aligned horizontally to the center of the screen
Hello, How can I make the Plasma/Kickoff app launcher always opening aligned horizontally to the center of the screen? I know that if I place the app launcher icon (button) on a center aligned panel, the app launcher opens in the center position of the screen. But if the app launcher icon has moved to the left (for example, when started app icons pushing the app launcher's icon to the left) and app launcher's icon position going lefter of left border of the app launcher, then the app launcher is jump to the left from screen center and centered by app launcher's icon (is not in the center of the screen). -- С уважением, Константин Макаров
[Powerdevil] [Bug 304696] Display is dimmed in half the time you configure to dim
https://bugs.kde.org/show_bug.cgi?id=304696 --- Comment #24 from Konstantin Kharlamov --- (In reply to Paul Gideon Dann from comment #23) > Is there some migration so that the currently-configured timeout doesn't > suddenly double at the next upgrade? Some of us have since configured our > systems to compensate for the 50% time behaviour. There isn't, but if you think it is a real problem I think it might be possible to revert the change from stable and just leave it be a breaking change for the next big 6.0 release… -- You are receiving this mail because: You are the assignee for the bug.
[Powerdevil] [Bug 304696] Display is dimmed in half the time you configure to dim
https://bugs.kde.org/show_bug.cgi?id=304696 Konstantin Kharlamov changed: What|Removed |Added Latest Commit|https://invent.kde.org/plas |https://invent.kde.org/plas |ma/powerdevil/-/commit/1464 |ma/powerdevil/-/commit/dc4a |7dc6ffd1104c1c0ab393518de8a |286037a802f3c18512e761b8908 |65cb39d70 |2740aa1e9 Version Fixed In|6.0 |5.27.8 --- Comment #22 from Konstantin Kharlamov --- Git commit dc4a286037a802f3c18512e761b89082740aa1e9 by Konstantin Kharlamov. Committed on 29/08/2023 at 01:42. Pushed by ngraham into branch 'Plasma/5.27'. dimdisplay: only dim the screen at configured dim time The current logic is completely broken: 1. It disables the screen at `m_dimOnIdleTime` even though disabling the screen is handled elsewhere with a separate timeout, and the logic here has prefix "Dim*" so has nothing to do with disabling it. 2. It does not follow the timeout configured by a user (that is the `m_dimOnIdleTime`) and instead dims the screen at completely arbitrary 50% and 75% periods of the configured time. Let's get rid of all that and only do exactly what the user asked: dim the screen at `m_dimOnIdleTime`. FIXED-IN: 5.27.8 M +10 -14 daemon/actions/bundled/dimdisplay.cpp https://invent.kde.org/plasma/powerdevil/-/commit/dc4a286037a802f3c18512e761b89082740aa1e9 -- You are receiving this mail because: You are the assignee for the bug.
[Powerdevil] [Bug 304696] Display is dimmed in half the time you configure to dim
https://bugs.kde.org/show_bug.cgi?id=304696 Konstantin Kharlamov changed: What|Removed |Added CC||hi-an...@yandex.ru --- Comment #19 from Konstantin Kharlamov --- I sent an MR to fix this https://invent.kde.org/plasma/powerdevil/-/merge_requests/213 -- You are receiving this mail because: You are the assignee for the bug.
Re: “Application Launcher 2.0” - New (simple) Feature Request
On Tue, 2021-03-16 at 10:35 +0100, Marco Uguccioni wrote: > Dear Mr. Martin Graesslin & Mr. Mikel Johnson, > > I am writing you to kindly request a new feature > in the new version of the Kickoff Menu which will be released with Plasma 5.21 > Stable: Should this suggestion go to a bugtracker instead? This would allow for anyone interested to pick this feature up and implement it. Who knows, it could even be you ;) The people you referred to I'm sure also work on something they deem important; and a priority is often a subjective thing. So, often the best way to ensure a feature one considers important is implemented is to try taking a stab at it.
D23039: Make Kickoff restore favorites order when dragging an item to desktop
lisin updated this revision to Diff 63407. lisin added a comment. Sure, I've added the comment REPOSITORY R119 Plasma Desktop CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D23039?vs=63398=63407 REVISION DETAIL https://phabricator.kde.org/D23039 AFFECTED FILES applets/kickoff/package/contents/ui/FavoritesView.qml applets/kickoff/package/contents/ui/Kickoff.qml applets/kickoff/package/contents/ui/KickoffListView.qml To: lisin, #plasma, ngraham, hein Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D23039: Make Kickoff restore favorites order when dragging an item to desktop
lisin updated this revision to Diff 63398. lisin added a comment. Added `isChildOf(source, favoritesView)` which is probably needed. REPOSITORY R119 Plasma Desktop CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D23039?vs=63397=63398 REVISION DETAIL https://phabricator.kde.org/D23039 AFFECTED FILES applets/kickoff/package/contents/ui/FavoritesView.qml applets/kickoff/package/contents/ui/Kickoff.qml applets/kickoff/package/contents/ui/KickoffListView.qml To: lisin, #plasma, ngraham, hein Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D23039: Make Kickoff restore favorites order when dragging an item to desktop
lisin added a comment. I was reluctant to introduce a new variable with such a broad scope (`kickoff.dragStartRow`) but using the `startRow` from `DropArea` would sometimes still mess up the order - the item would get the new value of `startRow` if the user moved the cursor back inside `DropArea`, so it would be snapping back to the wrong position. It's not really something a user would commonly do, so I can edit the code to use it instead. Otherwise, `startRow` wasn't used anywhere so I removed it completely. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D23039 To: lisin, #plasma, ngraham, hein Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D23039: Make Kickoff restore favorites order when dragging an item to desktop
lisin created this revision. lisin added reviewers: Plasma, ngraham, hein. Herald added a project: Plasma. Herald added a subscriber: plasma-devel. lisin requested review of this revision. REVISION SUMMARY This fixes the undesired reordering of the favorites which could happen when dragging an item to desktop by restoring the order of favorites when the cursor leaves Kickoff. BUG: 385856 REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D23039 AFFECTED FILES applets/kickoff/package/contents/ui/FavoritesView.qml applets/kickoff/package/contents/ui/Kickoff.qml applets/kickoff/package/contents/ui/KickoffListView.qml To: lisin, #plasma, ngraham, hein Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D22988: Fix incorrect Kickoff tab bar layout for vertical panels
lisin added a comment. Yes, getting into it was pretty straightforward and quick, KDE team did a great job! REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D22988 To: lisin, #plasma, hein, ngraham Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D22988: Fix incorrect Kickoff tab bar layout for vertical panels
lisin added a comment. Thank you, this was my first ever contribution to FOSS! I have submitted the fix for the TabBar here: https://phabricator.kde.org/D23036 I'm not quite sure about who to add as reviewers though. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D22988 To: lisin, #plasma, hein, ngraham Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D22988: Fix incorrect Kickoff tab bar layout for vertical panels
lisin updated this revision to Diff 63369. lisin edited the summary of this revision. lisin edited the test plan for this revision. lisin added a comment. Removed line 435. REPOSITORY R119 Plasma Desktop CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D22988?vs=63264=63369 REVISION DETAIL https://phabricator.kde.org/D22988 AFFECTED FILES applets/kickoff/package/contents/ui/FullRepresentation.qml To: lisin, #plasma, hein, ngraham Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D22988: Fix incorrect Kickoff tab bar layout for vertical panels
lisin added a comment. I also couldn't reproduce the gray overlay (which is caused by `tabBarSeparator` having a wrong size and taking the whole view - yesterday I could reproduce it but no more) that is shown in the comment 16 here: https://bugs.kde.org/show_bug.cgi?id=395390#c16 So it may still be present. Currently, I can't see any separator but it's a different issue. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D22988 To: lisin, #plasma, hein, ngraham Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D22988: Fix incorrect Kickoff tab bar layout for vertical panels
lisin created this revision. lisin added reviewers: Plasma, hein, ngraham. Herald added a project: Plasma. Herald added a subscriber: plasma-devel. lisin requested review of this revision. REVISION SUMMARY This fixes the incorrect initial positioning of the tab bar (first tab is placed out of bounds) when Kickoff is in a vertical panel that persists until the user selects another tab manually. BUG: 395390 And the broken layout of the tab bar (tab bar takes the whole view) when a panel is changed from horizontal to vertical that persists until plasmashell is restarted. BUG: 393888 TEST PLAN BUG: 395390 Place Kickoff in a vertical panel. Restart plasmashell and open Kickoff. Before fix: first tab is positioned out of bounds (y<0). After fix: first tab is positioned correctly (y=0). BUG: 393888 Change panel orientation from horizontal to vertical. Open Kickoff. Before fix: tab bar fills the whole view making the Kickoff unusable even if you make the panel horizontal again. After fix: tab bar has the correct size. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D22988 AFFECTED FILES applets/kickoff/package/contents/ui/FullRepresentation.qml To: lisin, #plasma, hein, ngraham Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D22988: Fix incorrect Kickoff tab bar layout for vertical panels
lisin added a comment. Line `onHeightChanged: onWidthChanged()` fixes BUG: 395390 I'm not sure if this is the best solution. For some reason, `plasmacomponents/qml/TabBar.qml` lacks an `onHeightChanged()` function but it has `onWidthChanged()` that seems to do what needs to happen here. Maybe `TabBar.qml` should be changed instead. The rest of the changes is for BUG: 393888 It seems to me that the removed code was a more clean way to do this, but it didn't update the values without restarting. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D22988 To: lisin, #plasma, hein, ngraham Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
Re: CI system maintainability
On Чт, Mar 28, 2019 at 19:40, Ben Cooksley wrote: Hi all, We currently have a rather substantial issue, in that the CI system has been once again left in a position where it isn't possible to make any changes to the system. This means we can't update to newer versions of packages, add new packages or correct for binary incompatible changes which periodically get introduced to non-Frameworks. This issue has arisen because currently we have a recurring failure to build from source, within KDE PIM. Specifically, KContacts fails due to broken CMake logic. Despite this breakage having been in place for several days now, and the relevant mailing list being informed automatically by the CI system, the issue has not been corrected. While the most immediate fix is to correct this failure to build from source, that is only a short term fix and does not fix the underlying issue which makes the CI system difficult to maintain - and that is build failure reports being ignored, and people pushing broken code that doesn't even build. (For those wondering, the CI system uses OpenSUSE Tumbleweed, a rolling release distribution, for it's builds, so it isn't a case of old CMake or anything along those lines) We therefore need a long term fix for this. Note that pre-commit (as part of review) CI is not a solution in this instance, as the offending commits did not go through review. Does anyone have any ideas for a long term, proper fix to this? At this point given the amount of effort required to maintain a CI system vs. the amount of care actually being given by some developers (who are ignoring it's failure emails) it becomes questionable whether the effort is worth the return (and if not, we should just shut it down) Regards, Ben Cooksley KDE Sysadmin I don't know abut the current CI, but judging by recent discussion that is about KDE migrating to gitlab; quick search shows gitlab does allow prohibiting a merge if CI failed¹ Note however, in my experience of contributing to diffrent project CI often fails for reasons absolutely irrelevant to code being tested (e.g. errors in a CI script), in this case prohibiting a merge may worsen the situation. 1: https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds
D10461: GMenu-DBusMenu-Proxy
rilian added a comment. UPD: disabled an exporting of empty menubar on X11. Try latest appmenu-gtk-module master, please. I do not know how to do it in GTK Wayland. Can you explain me KDE Wayland Global Menu architecture? REPOSITORY R120 Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D10461 To: broulik, #plasma Cc: rk, rilian, mtallur, ngraham, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D10461: GMenu-DBusMenu-Proxy
rilian added a comment.
If you need help, I will provide it for you, because for me there is 2
features which should be in KDE for me:
1. Global Menu (for all protocols)
2. QGtkStyle (with GTK3 themes)
> Okay. Problem is that for example LibreOffice doesn't have a menu right
away, so I can't realy tell "no menu because it's still loading" or "no menu
because it doesn't have one" and then fallback to app menu. I could perhaps
check if the app has an appmenu at all before trying to fallback but not really
fond of adding even more complexity to it.
I too because MenuModel can be empty on start, and I cannot differ than user
turned menu off or just application do not have a menu?
About searching of appmenu and fallback to it - LibreOffice have both appmenu
and menubar, so, we will lose LibreOffice menu.
> What kind of different actions? So far I have only had redundancy in the
app menu, I'll try to look into this, merging two separate menus into one
somehow, also getting the app name for the app menu..
It can be actions (GActions, I mean) than exists only in appmenu, but not in
menubar. User may want this.
> How am I supposed to know which action belongs where?
But all menuitems have "action" attribute)
Or if you about a QAction (which, I think, should called QMenuItem), this is
several ways to do this:
1. Look for each section, name it by some action-name regex (as you did with
icons) and then show it as menubar.
2. Or just do it with each menuitem, but it is way more complicated. I
suggest a section-way.
> That was just for the icon mapping, I can probably remove this, since the
actions in unity are just their localized labels plus unity. prefix, there's
nothing I can map them to (like I would be able to window.open to document-open
icon)
I think you do not need mapping, because we have a bunch of this code:
C
static GtkImage *gtk_menu_item_get_nth_image(GtkMenuItem *menu_item, guint
index)
{
UnityGtkSearch search;
g_return_val_if_fail(GTK_IS_MENU_ITEM(menu_item), NULL);
search.type = GTK_TYPE_IMAGE;
search.index = index;
search.object = NULL;
g_object_get_nth_object(G_OBJECT(menu_item), );
return search.object != NULL ? GTK_IMAGE(search.object) : NULL;
}
static GIcon *gtk_image_get_icon(GtkImage *image)
{
GIcon *icon = NULL;
g_return_val_if_fail(GTK_IS_IMAGE(image), NULL);
switch (gtk_image_get_storage_type(image))
{
case GTK_IMAGE_GICON:
{
gtk_image_get_gicon(image, , NULL);
if (icon != NULL)
g_object_ref(icon);
}
break;
case GTK_IMAGE_ICON_NAME:
{
const char *name = NULL;
gtk_image_get_icon_name(image, , NULL);
if (name != NULL)
icon =
G_ICON(g_themed_icon_new_with_default_fallbacks(name));
}
break;
case GTK_IMAGE_PIXBUF:
{
GdkPixbuf *pixbuf = gtk_image_get_pixbuf(image);
if (pixbuf != NULL)
icon = g_object_ref(pixbuf);
}
break;
case GTK_IMAGE_ANIMATION:
{
GdkPixbufAnimation *animation = gtk_image_get_animation(image);
if (animation != NULL)
{
GdkPixbuf *pixbuf =
gdk_pixbuf_animation_get_static_image(animation);
if (pixbuf != NULL)
icon = g_object_ref(pixbuf);
}
}
break;
case GTK_IMAGE_STOCK:
#if GTK_MAJOR_VERSION == 2
{
char *stock = NULL;
GtkIconSize size = GTK_ICON_SIZE_INVALID;
gtk_image_get_stock(image, , );
if (stock != NULL)
{
GdkPixbuf *pixbuf =
gtk_widget_render_icon(GTK_WIDGET(image), stock,
size, NULL);
if (pixbuf != NULL)
icon = G_ICON(pixbuf);
}
}
#elif GTK_MAJOR_VERSION == 3
{
GtkStyleContext *context =
gtk_widget_get_style_context(GTK_WIDGET(image));
if (context != NULL)
{
char *stock = NULL;
GtkIconSize size = GTK_ICON_SIZE_INVALID;
gtk_image_get_stock(image, , );
if (stock != NULL)
{
GtkIconSet *set =
gtk_style_context_lookup_icon_set(context, stock);
if (set != NULL)
{
D10461: GMenu-DBusMenu-Proxy
rilian added a comment. What about FIXME unity, what are you mean? I can fix appmenu-gtk-module for you. REPOSITORY R120 Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D10461 To: broulik, #plasma Cc: rk, rilian, mtallur, ngraham, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D10461: GMenu-DBusMenu-Proxy
rilian added a comment. O, some another note: You can generate menubar from appmenu. For example, Nautilus: It have 4 sections 1. New Window 2. Sidebar 3. Preferences 4. Keyboard Shortcuts Help About Quit. You can add New Window and Quit to File menu, Sidebar to View, Preferences and Keyboard shortcuts to Tools (or Edit), and Help and About to help. REPOSITORY R120 Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D10461 To: broulik, #plasma Cc: rk, rilian, mtallur, ngraham, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D10461: GMenu-DBusMenu-Proxy
rilian added a comment. 1. Yes, menubar may be empty with appmenu-gtk-module or unity-gtk-module, and if I can fix appmenu-gtk-module, unity-gtk-module will not be fixed. So, I think it is preferred to check on your side. 2. GTK3 applications (file-roller, for example) can use both appmenu and menubar with different items (and different action) . So, I think, hiding appmenu is bad, because user may want this menu entries. REPOSITORY R120 Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D10461 To: broulik, #plasma Cc: rk, rilian, mtallur, ngraham, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D10461: GMenu-DBusMenu-Proxy
rilian added a comment. Thanks so much) 1. Unity is dead, but I forked unity-gtk-module, patched it for all distros, fixed some bugs and called appmenu-gtk-module. So, Unity is dead, but unity action prefixes is live. 2. To use unity-gtk-module or appmenu-gtk-module you need to install it into correct location (where all gtk modules is located) and then add its name (unity-gtk-module or appmenu-gtk-module) to environment variable called GTK_MODULES. If it will not working with appmenu-gtk-module, write me. unity-gtk-module maintainers is not so responsive. 3. Menu can use only application actions, only window actions and only unity actions. And all this are correct, as well as any combination of it (but not empty combination). REPOSITORY R120 Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D10461 To: broulik, #plasma Cc: rk, rilian, mtallur, ngraham, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D10461: GMenu-DBusMenu-Proxy
rilian added a comment. Hello, I am Konstantin, developer of vala-panel-appmenu. I have some comments about your application. MenuModel protocol consitsts for 5 items: AppMenu - with property _GTK_APPMENU_OBJECT_PATH MenuBar - with property _GTK_MENUBAR_OBJECT_PATH It is a menu models, it is how menu should drawn on screen. One can be missing, and then incomplete menu should render: a) If AppMenu is missing, you will miss menu entry with application name (vala-panel-appmenu renders stub in place of missing AppMenu) b) If MenuBar is missing, you will miss all menu entries except entry with application name. c) If both are missing, you will not see a menu (Protocol is incorrect) And 3 providers of actions. Actions is required to get menu react on user changes.Providers: Application (_GTK_APPLICATION_OBJECT_PATH, prefix app) - it is actions from all application (not bound to a particular window) Window (_GTK_WINDOW_OBJECT_PATH, prefix win) - it is actions from current window, as it set by a developer of application Unity (_UNITY_OBJECT_PATH, prefix unity) - it is non-standard, but widely used action path for set a Unity actions (when window actions is not supported by app developer). It is object path supported by unity-gtk-module and appmenu-gtk-module. If you implement this, you will get GTK2 menu for free. If any of this are missing, this menu items should be rendered as disabled. But if menu using actions only from one category - it can be used as a normal menu. Setting this all is not required for functional menu. One will be enough, if menu is using actions only from one group. REPOSITORY R120 Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D10461 To: broulik, #plasma Cc: rilian, mtallur, ngraham, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
[Differential] [Commented On] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa added a comment. In https://phabricator.kde.org/D4204#80553, @davidedmundson wrote: > Though really any max > min on the client is undefined behaviour, so it's hard to say any is "right". You are right. It's undefined behaviour. At current state there is a hole in mechanis: plasmoid.Layout.minimumHeight = 150 plasmoid.Layout.maximumHeight = 130 plasmoid.Layout.maximumHeight = 150 because Qt wouldn't emit signal - Layout.minimumHeight is not changed. But I don't think that it can be fixed, it's just how QML works, and it's a user job to be sure that at his end these values are alright. > Anyway, I think there's still room for improvements in this file overall (mostly with the existing structure), but for now I think this is good to go. I've been testing it for a day, seems to work fine. Including with RTL. Thanks! REPOSITORY R119 Plasma Desktop BRANCH plasmoid_size_restraints REVISION DETAIL https://phabricator.kde.org/D4204 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, davidedmundson, #plasma Cc: mart, davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Updated, 305 lines] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa updated this revision to Diff 10599. konstantinshtepa added a comment. Fixed littke bug which would happend with code plasmoid.Layout.minimumHeight = 150 plasmoid.Layout.maximumHeight = 130 plasmoid.Layout.maximumHeight = 150 Bug led to maximumHeight = 150 when minimumHeight would still be = 130 REPOSITORY R119 Plasma Desktop CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D4204?vs=10593=10599 BRANCH plasmoid_size_restraints REVISION DETAIL https://phabricator.kde.org/D4204 AFFECTED FILES containments/desktop/package/contents/ui/AppletAppearance.qml containments/desktop/package/contents/ui/AppletHandle.qml EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, davidedmundson, #plasma Cc: mart, davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Updated] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa updated the summary for this revision. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D4204 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: mart, davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Commented On] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa added inline comments. INLINE COMMENTS > davidedmundson wrote in AppletAppearance.qml:445 > Edit, maybe it won't - that's why you have the separate Binding. > > However changing this to: > minimumWidth: Math.min(minimumSize.width, maximumSize.width); > > for all 4 > > would still be a bit cleaner as then appletItem can trust these values are > correct Ok, I removed bindings at cost of two additional handlers. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D4204 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: mart, davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Updated, 297 lines] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa updated this revision to Diff 10593. konstantinshtepa marked an inline comment as done. konstantinshtepa added a comment. Removed Bindings REPOSITORY R119 Plasma Desktop CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D4204?vs=10453=10593 BRANCH plasmoid_size_restraints REVISION DETAIL https://phabricator.kde.org/D4204 AFFECTED FILES containments/desktop/package/contents/ui/AppletAppearance.qml containments/desktop/package/contents/ui/AppletHandle.qml EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: mart, davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Commented On] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa added a comment.
In https://phabricator.kde.org/D4204#80142, @mart wrote:
> what i would like to have logically splitted is the management of the
floating property (and having positionItem()/releasePosition used around)
>
> and on the other hand the signal handlers of
minimumWidthChanged/widthChanged etc in Appletappearance, that's the biggest
part
Sorry, I don't understand what you would like me to do. Do you like me to
split code to add additional commit where would be introduced managment of
floating property? But why? it's useless without others bug 375307(fixes of
work with layoutManager) fixes. And to split bug 375307 fixes from bug
375308(maximumSize handlers) is big work for me, because all my work centered
over bug 375308. Other bugs were founded when debugging bug 375308 fixes.
Because of that bug 375307 fixes is never were intended by me as standalone,
they currently included only as additional bug fixing to bug 375308 fixes.
I can compress some code in handlers by adding function like
function setSizePropertyAndReposition(sizeProperty, newSizeProperty) {
releasePosition();
sizeProperty = newSizeProperty;
positionItem();
if (showAppletHandle && !handleMerged)
appletHandle.positionHandle();
}
Should I do it?
P.S. I understand that this code is not well. But in first place it couldn't
be well because current state of plasmoid background code is in mess and it
need to be rewritten. What I propose in this diff is temporary solution which
fixes bugs until I or somebody else would rewrite plasmoid background to normal
code.
REPOSITORY
R119 Plasma Desktop
REVISION DETAIL
https://phabricator.kde.org/D4204
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: konstantinshtepa, #plasma
Cc: mart, davidedmundson, plasma-devel, lesliezhai, ali-mohamed,
jensreuterberg, abetts, sebas
[Differential] [Commented On] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa added inline comments. INLINE COMMENTS > davidedmundson wrote in AppletAppearance.qml:445 > Edit, maybe it won't - that's why you have the separate Binding. > > However changing this to: > minimumWidth: Math.min(minimumSize.width, maximumSize.width); > > for all 4 > > would still be a bit cleaner as then appletItem can trust these values are > correct It wouldn't work. For example: plasmoid.Layout.minimumHeight = 150 plasmoid.Layout.maximumHeight = 200 plasmoid.Layout.maximumHeight = 130 On third step it would think that maximumHeight = 150 and minimumHeight = 130, when it should think that maximumHeight = minimumHeight = 130. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D4204 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: mart, davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Commented On] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa added inline comments. INLINE COMMENTS > davidedmundson wrote in AppletAppearance.qml:445 > Edit, maybe it won't - that's why you have the separate Binding. > > However changing this to: > minimumWidth: Math.min(minimumSize.width, maximumSize.width); > > for all 4 > > would still be a bit cleaner as then appletItem can trust these values are > correct Ok. I didn't think about this possibility. Maybe you are right and it would be better. If so then I can remove separate bindings. I will test it. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D4204 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: mart, davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Commented On] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa added inline comments. INLINE COMMENTS > davidedmundson wrote in AppletAppearance.qml:101 > this is broken. > > if I'm an applet and do: > Plasmoid.Layout.maximumWidth = 50 > > this appletItem.maximumWidth == 58 (assuming 4px margins) > which is correct > > Now if I do: > > Plasmoid.Layout.minimumWidth = 60 > > this appletItem.maximumWidth == 68 > which is also fine, we've set it to the minimum + margins > > But, now if I do: > > Plasmoid.Layout.maximumWidth = 70 > this appletItem.maximumWidth == 68 > > because we've broken the binding. > > We're going to need to move the > > if (minimumWidth > maximumWidth) > maximumWidth = minimumWidth; > > logic somewhere lower. > Either into appletContainer or even AppletQuickItem where it does the > proxying. That's strange. I didn't expirienced any of this when testing. Binding on level appletItem.maximumWidth shouldn't be broken because they based on external Binding QML element. I will look into this. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D4204 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: mart, davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Updated] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa updated the summary for this revision. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D4204 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: mart, davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Commented On] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa added a comment. In https://phabricator.kde.org/D4204#80106, @mart wrote: > can this be splitted in multiple reviews/commits? It can be splitted into multiple commits inside one branch so you can view what exactly fix what. But multiple reviews based on master? I don't think so. All patches have intersections and patch of Bug 375308 heavily depends on patch of Bug 375307. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D4204 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: mart, davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Updated, 305 lines] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa updated this revision to Diff 10453. konstantinshtepa added a comment. Rewrited some code to better understanding Fixed background-handle animation in plasmoidBackground. It was a little bug, but I don't see any sense to report it now when patch are ready. Fixed it by changing it to animate only handle-width instead of animation of full plasmoidBackground width. REPOSITORY R119 Plasma Desktop CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D4204?vs=10447=10453 BRANCH plasmoid_size_restraints REVISION DETAIL https://phabricator.kde.org/D4204 AFFECTED FILES containments/desktop/package/contents/ui/AppletAppearance.qml containments/desktop/package/contents/ui/AppletHandle.qml EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Commented On] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa added a comment. A detailed explanation of bugs, fixes and mechanics changes === Before anything else I'd like to explain why I need this patch. At winter holidays I had a free time and decided to rewrite plasma-simplemonitor(maded by dhabyx) - port it to plasma5 and improve it. As one of new features I added "skins" - posibility to change UI looks. Let's describe one skin as "row" and other as "column". Skins had different default sizes and different minimum sizes. As behaviour it sugges that when user change one skin to another plasmoid size supposed to change to default size of new skin. In plasma5 there is no resize function in plasmoid anymore. Instead docs pointed to use Layout properties. And so I tried to set maximum sizes in Layout. It doesn't work. When researching this problem it was occurred that there is no such functionality in plasmoids despite that plasmoid already uses Layout minimum sizes. And so I made this patch to fix that. When debugging this patch I found other bugs and fixed them alongside. **To read next you should understand QML and Qt/C++. Especially what is QPropertyAnimation, how it works and behave over object properties.** I would mention bugs in order of it's difficulties and their involvement in patch. From easy to hard. 1. Bug 375349 (Plasmoid can't be resized to declared minimumWidth). This bug was because of mess in size relationship. Because of it plasmoid wouldn't get smaller than Layout.minimumWidth + 2 * handleWidth. Bug was in appletItem minimumWidth calculation and in AppletHandler.qml resize calculation(resizeHandle.onPositionChanged) . 2. Bug 375307 (Sometimes Plasmoid doesn't free all his space in LayoutManager), Bug happens because of appletItem size animations. Let's see how bug happening. User is done resizing appletItem, after that appletItem would be resized and positioned in layoutManager to fit cell politics, result sizes and position would be locked in layoutManager as area which used by this plasmoid. Now will start animation over applet height, width, x and y. Guess what would happend if somebody tried to move plasmoid or resize it in exact that moment? Yup. appletItem would try to release area in layoutManager with current(still animated) properties which != end properies. And it would lead to some area in layoutManager to not release properly. I did many things(for example tried to implement and use "end" properties) to patch this but I think that it should be fully patched with implemtation of appletItem.floating property and functions positionItem and releasePosition which now handle all operations over layoutManager to lock\unlock area. 3. Bug 375308 (Plasmoid applet doesn't have maximum size handlers) When implementing this patch I encountered several questions: - What to do in case of minimum > maximum size? I think that when this happened the other restrictive size should be changed to match new one. So I added this behaviour to all changes handlers of restrictive sizes. It also broke normal qml binding of restrictive sizes, but I solved it with using of QML Binding Items. - What to do with qreal -> int convertation for maxinum size? Default maxsize is Number.POSITIVE_INFINITY and that it would be autoconverted into int.NEGATIVE_MAX_VALUE which is not good. So I added simple check to see if qreal value would be too much to handle in int. And if it so to change it to 100. I don't have any better idea how to handle this. - What to do when appletItem size set by layoutManager would be > than maximumSize? I created "innerAppletItem" in face of mouseListener. To handle all of animations I created additional properties like endHeight, endX, etc. "End" - because they symbolise what height, x, and other would be at end of animation. With these additional properties current end values always known and using them "innerAppletItem" can handle all kind of size and position changes even when it animations are running. - What to do when plasmoid is moved to new place and animations is on? Because of this I just can not write in "innerAppletItem"(mouseListener) "anchors.centerIn: parent". So I implemented x and y change handlers in appletItem which would move position of "innerAppletItem" to place of old center(where it was according to appletItem.parent coordinates) and then play animation of move to a new place. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D4204 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Updated] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa updated the summary for this revision. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D4204 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Updated, 310 lines] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa updated this revision to Diff 10447. konstantinshtepa added a comment. Fix commit message REPOSITORY R119 Plasma Desktop CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D4204?vs=10446=10447 BRANCH plasmoid_size_restraints REVISION DETAIL https://phabricator.kde.org/D4204 AFFECTED FILES containments/desktop/package/contents/ui/AppletAppearance.qml containments/desktop/package/contents/ui/AppletHandle.qml EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Updated, 310 lines] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa updated this revision to Diff 10446. konstantinshtepa added a comment. Turn on background width animation again. REPOSITORY R119 Plasma Desktop CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D4204?vs=10408=10446 BRANCH plasmoid_size_restraints REVISION DETAIL https://phabricator.kde.org/D4204 AFFECTED FILES containments/desktop/package/contents/ui/AppletAppearance.qml containments/desktop/package/contents/ui/AppletHandle.qml EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Updated, 318 lines] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa updated this revision to Diff 10408. konstantinshtepa added a comment. Rewrited commit message in according to kde commit polititcs REPOSITORY R119 Plasma Desktop CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D4204?vs=10407=10408 BRANCH plasmoid_size_restraints REVISION DETAIL https://phabricator.kde.org/D4204 AFFECTED FILES containments/desktop/package/contents/ui/AppletAppearance.qml containments/desktop/package/contents/ui/AppletHandle.qml EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Updated] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa updated the summary for this revision. konstantinshtepa updated the test plan for this revision. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D4204 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Updated, 318 lines] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa updated this revision to Diff 10407. konstantinshtepa added a comment. Summary: reworked set of patches to plasma-desktop/containments/desktop to fix bugs in plasmoid. Fix for - plasmoid applet missing maximum size handler - plasmoid can't be set to declared minimumWidth - plasmoid don't release space in layoutManager.properly due to size animations GUI BUG: 375349,375308,375307 REPOSITORY R119 Plasma Desktop CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D4204?vs=10359=10407 BRANCH plasmoid_size_restraints REVISION DETAIL https://phabricator.kde.org/D4204 AFFECTED FILES containments/desktop/package/contents/ui/AppletAppearance.qml containments/desktop/package/contents/ui/AppletHandle.qml EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Commented On] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa added a comment. WARNING: Found a bug with plasmoid don't free all his space in LayoutManager when changed from compactRepresentation to fullRepresentation. Don't push this patch before I fix this bug. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D4204 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Commented On] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa added a comment.
In https://phabricator.kde.org/D4204#78701, @davidedmundson wrote:
> That's quite a huge patch.
> Can you give a much bigger explanation on exactly what it's doing and why.
> "Fixes bug N" doesn't really explain what the original problem was.
Sorry, diff not supposed to be send here today and in that kind of state. And
I don't see here any way to delete this diff and close this theme. Because of
this information is not fully ready.
I would tomorrow add comments to code about what code does and why.
INLINE COMMENTS
> davidedmundson wrote in AppletAppearance.qml:61
> why do you do
>
> property int foo
> Binding on foo {
> value: Math.max()
> }
>
> instead of just
>
> property int foo: Math.max
>
> ?
Binding on properties used because these properties assigned in JS(in handlers
onMinimumWidthChanged and others) as lvalue and it breaks normal bindings. If
someone could bring better idea how to handle situation when minimum size >
maximum size without these bindings then they can be removed.
> davidedmundson wrote in AppletAppearance.qml:226
> Point is a native QML type.
> http://doc.qt.io/qt-5/qml-point.html
>
> property point lastPoint
>
> then use that in your logic above.
> It can be better because you then get one signal when it changes not two.
You can go without links. I know Qt, commited there.
One signal when it doesn't have any handlers or bindings wouldn't change any
weather in QML. Point too have it's negative sides because it needs
inverpretation "lastPoint.x". The question here is maybe I should have used int
too as a base to properties(to maintain policy of int-based sizes).
> davidedmundson wrote in AppletAppearance.qml:445
> if maximum is infinite, (so undefined in QtQuick.Layouts) set it to 100
>
> why?
> It's far easier to test for isFinite() in other bits of code than a random
> big init
Just a few lines below this size is assigned for property with int as a base.
Then this property is used in operations with others int-based kde sizes. And
keep it as double is not a option because of default Qt
maximumSize(Number.POSITIVE_INFINITY). So there goes 100. Is there better
way?
REPOSITORY
R119 Plasma Desktop
REVISION DETAIL
https://phabricator.kde.org/D4204
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: konstantinshtepa, #plasma
Cc: davidedmundson, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg,
abetts, sebas
[Differential] [Changed Policy] D4204: Patch for plasmoid subsystem(containments/desktop) in plasma-desktop
konstantinshtepa changed the visibility from "konstantinshtepa (Konstantin Shtepa)" to "Public (No Login Required)". konstantinshtepa changed the edit policy from "konstantinshtepa (Konstantin Shtepa)" to "All Users". REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D4204 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa, #plasma Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Request, 320 lines] D4204: Added max size restrictions handlers for plasmoids
konstantinshtepa created this revision. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY Signed-off-by: Konstantin Shtepa <oss.konstantin.sht...@yandex.ru> first step release commit. Bugs fixed, plasmoid behaves as expected. Signed-off-by: Konstantin Shtepa <oss.konstantin.sht...@yandex.ru> fixed handle width bug Signed-off-by: Konstantin Shtepa <oss.konstantin.sht...@yandex.ru> Fixed bug with plasmoid geometry not saved properly Signed-off-by: Konstantin Shtepa <oss.konstantin.sht...@yandex.ru> REPOSITORY R119 Plasma Desktop BRANCH plasmoid_size_restraints REVISION DETAIL https://phabricator.kde.org/D4204 AFFECTED FILES containments/desktop/package/contents/ui/AppletAppearance.qml containments/desktop/package/contents/ui/AppletHandle.qml EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: konstantinshtepa Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
Re: [Development] Qt Quick Controls Calendar
I've missed that, sorry. Can we discuss the code right in the
https://codereview.qt-project.org/#change,73340 's diff?
Regards,
Konstantin
2014/1/2 Mitch Curtis mitch.cur...@digia.com
On 12/22/2013 05:51 AM, Konstantin Ritt wrote:
During the testing, we've found a bunch of bugs and other issues. I'd
suggest uploading this WIP branch to codereview, like we do for any
other stuff.
Regards,
Konstantin
It has been on gerrit in a WIP branch since I sent the email you replied
to; it's all there in the original email.
2013/12/21 Mark Gaiser mark...@gmail.com mailto:mark...@gmail.com
On Fri, Dec 6, 2013 at 4:11 PM, Mitch Curtis mitch.cur...@digia.com
mailto:mitch.cur...@digia.com wrote:
On 12/06/2013 03:08 PM, Mark Gaiser wrote:
On Fri, Dec 6, 2013 at 2:02 PM, Mitch Curtis
mitch.cur...@digia.com mailto:mitch.cur...@digia.com
wrote:
Hello.
At the beginning of this year I started work on a Calendar for Qt
Quick
Controls as a sort of side project. After removing the WIP from
the
commit message, I got some feedback from developers who either a)
had
also wrote a Calendar for KDE stuff or b) suggested I ask for
feedback
from plasma-devel. Rather than add to the already massive list of
patch
sets for that change, I thought it would be better to truly open
up the
Calendar for contributions before it goes in by creating a WIP
branch
for it in the Qt Quick Controls repo [1]:
wip/calendar
It'll be a throwaway branch, so every commit must be atomic and
follow
all of the normal Qt commit policies [2][3]. At the end, we'll
resubmit
every individual change to qtquickcontrols' dev branch.
I've been told that this is incorrect; the correct statement is:
even though this is a throw-away branch (whose commits will be
re-submitted
to dev individually), the usual policies should be followed
Please feel free to submit patches or provide feedback on what's
already
there. For example, it has already been suggested that there
should be a
C++ backend for the models, dates, etc.
Cheers.
[1]
https://qt.gitorious.org/qt/qtquickcontrols/source/
4c3196c979d9a7f46b3f37b14140026dd74bf79a
[2]http://qt-project.org/wiki/Branch-Guidelines
[3]http://qt-project.org/wiki/Commit_Policy
Hi Mitch,
It's awesome that you pull in the KDE plasma folks. I wonder who
gave
you that idea? ;)
Below is my feature list that i'd like to have in that calendar.
Since i have some experience in that area i will try to help out as
much as i can.
-- QML part --
* Controls for the calendar grid
* Controls for next/forward or just a few functions. This should at
least have a nextMonth/previousMonth. Perhaps also nextYear and
previousYear for convenience.
* Controls for the day names (mon, tue, wed, thu, fri, sat, sun).
And
the ability to change the name to shorter/longer variants.
* Controls for the weeknumbers that are shown in the grid.
As far as i understand the QML code, all but the weeknumbers are
in.
Yep.
-- Locale --
In KDE there was already an issue with differences between the
JavaScript date object and the QDate object. I don't know the fine
details here, someone else will probably fill that in i hope. I
know
there where issues, just not what exactly.
From the testing that I did with it [1], it has some differences
when it's a
negative year, so the current implementation of the Calendar only
allows
positive years, up to the year 275759; a significantly smaller
range than
QDate [2].
-- C++ part --
This is the part where i really would like some feedback. I have a
general idea of how it should be done, but i don't know the
details or
implications it might have.
It is my hope that calendar controls like Mitch is proposing now
will
be extensive enough to simply swap the models to another backend.
Akonadi comes to mind. However, there should obviously be a
non-akonadi based version for default Qt usage.
My idea on that is as follows. Again, i don't know the
implications of
it or if it's really viable to take this route. Feedback is very
much
welcome here!
The calendar model should be based on a new model that provides
some
default functionality and properties. I would say:
QAbstractCalendarModel : public QAbstractListModel { ... }
This model should provide the default - should be implemented -
properties:
* day -- INT number of the day in a current month
* isCurrentMonth -- returns true for the current month (aka, the
month
you
