Created attachment 113891 [details] Screenshot Styles inherit options from their parents. Once you change an option in a child style, there is no easy way to revert one single change so that inheriting the value would work. IMHO it would be useful, I sometimes miss it.
The attachment screenshot tries to visualise the use case. Main text style inherits everything from the default style unless it has a local override. All the overrides are nicely listed, there just is no way to easily remove override one by one. You can remove overrides for whole page when opening the page and clicking "Standard" button below the dialog.
Created attachment 114176 [details] One possible way of expressing Kendy's awesome idea.
Thought it was my awesome idea. :D
Sorry. I think I need to make a cheatsheet with IRC nicknames, Google aliases, real names and photos.
Migrating Whiteboard tags to Keywords: (needsDevEval, topicUI) [NinjaEdit]
*** Bug 127708 has been marked as a duplicate of this bug. ***
I believe this is quite an important feature to implement for enabling complex style hierarchies for documents. Regarding the mock-up in attachment 114176 [details]: I support this, but would suggest that the pieces of text would be put into "breadcrumbs", i.e. small slabs containing the text, which can be destroyed/deleted using an [x] button on their sides. I think this would be better than a superscript-[x]. Also, I believe this shouldn't be the only UI aspect for reverting/deleting individual settings. I would also like to see deletions, within the parts of the dialog where we actually set values, resulting in reversions to "no setting".
*** Bug 133107 has been marked as a duplicate of this bug. ***
*** Bug 136341 has been marked as a duplicate of this bug. ***
I'd like to emphasize the importance of this feature: At the moment you cannot "undo" a mistake in the styles. That makes it very simple to "fuck up" an important style in the document and then the only solution is to create a new style, replace the broken style, and so on. This makes long-term management of complex documents unnecessarily hard and prevents professional use for some. "fuck up" means that for example I have an inherited style that should only change the font but not the size. If I once accidentally set also the size, it will always carry its own size setting and not inherit the size from the parent any more. About the suggestion with the X in the style list: I think that this is probably the easiest to implement as it would require only changing a single UI element (the overview list) vs. updating all the other style UI elements to support 3 states (on, off, inherit) or to add "(inherit)" as a list item in the drop down lists. Therefore I'd like to suggest to first implement the X removal in the overview and then, maybe, also add inheritance as a choice in the individual style settings.
(In reply to Schlomo Schapiro from comment #10) > At the moment you cannot "undo" a mistake in the styles. Well, you can, but only by manually editing the relevant ODF file :-( > Therefore I'd like to suggest to first implement the X removal in the > overview and then, maybe, also add inheritance as a choice in the individual > style settings. Seems like a decent idea to start with that. We could also consider "bubbles" or "boxes" of indentation around the items, with the x's on their perimeter, as a kind of decoration. As for the settings themselves, elsewhere in the dialog, we could also consider some kind hover-behavior for settings in their respective parts of their dialog, which would include the ability to reset them to inheritance. But again - x's seem like a not-too-difficult thing to do.
I sent a patch to solve this bug: https://gerrit.libreoffice.org/c/core/+/199318
Created attachment 205489 [details] Added buttons to remove properties from child paragraph style
(In reply to Paolo Benvenuto from comment #13) > Created attachment 205489 [details] > Added buttons to remove properties from child paragraph style That feels like way too much spacing. Plus, please test this with a lower resolution: 1280x800. I suggest an implementation similar to mahfiaz' suggestion, i.e. * Keeping the layout very similar to what it was before * ... expect for just a bit of space to fit the 'x' mark * suggest the X mark after rather than before the change descriptions, and a little upwards, as if you put it at the corner of a tight box containing the change description * Filling rows with change descriptions rather than creating what seems like a grid arrangement which is what I (think I) see in the screenshot. * if possible, let change descriptions overflow to the next line rather than keeping them on the same line. Beyond that, something we might consider is actually painting weak-color-difference boxes around the text, with thin spaces between boxes. The it would look like we're removing 'stickers. But that's just a thought; the items above I feel more strongly about.
> * Keeping the layout very similar to what it was before I subdivided the changed properties by their tab because many properties have cryptic words: for example, selecting a color in the area tab produces the property "continous", which is impossible, without the organization by tab, to understand what it refers to. > * ... expect for just a bit of space to fit the 'x' mark A preliminar version of the patch simply added the x mark after the property, but I had problems with long lines when the changed properties are many. I'm trying again... > * suggest the X mark after rather than before the change descriptions, and a little upwards, as if you put it at the corner of a tight box containing the change description The position after were correct in case of the properties put one after the other, but not in current layout. Anyway I'm going to keep experimenting. > * Filling rows with change descriptions rather than creating what seems like a grid arrangement which is what I (think I) see in the screenshot. Let me try... > * if possible, let change descriptions overflow to the next line rather than keeping them on the same line. Explain better > Beyond that, something we might consider is actually painting weak-color-difference boxes around the text, with thin spaces between boxes. The it would look like we're removing 'stickers. But that's just a thought; the items above I feel more strongly about. Ok
From an end-user perspective I'd like to share that I like the structured view of the style content very much. Helps me a lot to see what is where and what is relevant. May I suggest a thought for the UX? Instead of having individual X marks on every item we could also have a big button labeled "Edit" in this area, or maybe "Remove single setting" or such, which would enable the X marks. That way the X marks can be larger and more visible and easer to use without getting in the way of just viewing. WDYT?
(In reply to Schlomo Schapiro from comment #16) > From an end-user perspective I'd like to share that I like the structured > view of the style content very much. Helps me a lot to see what is where and > what is relevant. Well... the "structured view of the style" is the dialog itself - that's how we see what's in it; this part is intended to be a concise textual representation. - and something that you can copy and paste as text (although - we can't actually copy the text as things stand right now). The problem with this structuring is that it will _prevent_ you from seeing what's in the style. If the style has several properties set in many categories, they'll just go off the end of the space available for the dialog. And - remember the dialog must fit a 1280x800-resolution monitor, so we can't just make it bigger. If Paolo can squeeze the categorized style contents into the dialog - in the case of _all_ properties being defined, then I can live with it, but I frankly kind of doubt this will work.
I get it, and short of having a scroll bar appear on overflow I don't see a solution. Would a scroll bar be bad for those cases where there is an overflow? I imagine that in >90% of all cases a style won't have so many settings to need it. ATM we have a textual representation of the style properties. What happens with that on overflow? Or is that something so seldom that we could ignore it so far?
> Instead of having individual X marks on every item we could also have a big button labeled "Edit" in this area, or maybe "Remove single setting" or such, which would enable the X marks good idea!
Hey, this is great progress. I like the aesthetics and organised look of Paolo's screenshot, this with less whitespace and scrollbar when needed would be perfect. Maybe the options could be inline/variable-width button/without being arranged to a grid to save space. All the other proposed solutions would work just fine as well.
@Mike You did give some input on bug 88559, so might be interest in following this one too. This bug and bug 88559 are - in my perception - different sides of the same coin. Being able to 'reset' a property requires knowledge about the inheritance state of the property, so makes the inheritance visible.
Created attachment 205526 [details] Screenshot Table of Content Dialog A) Nice that someone is working on this. Surely appreciated! B) The 'Contains' is listing the differences between this style and the Parent Style. So it actually acts as a kind of summary, if I understand correctly [not too familiar with the matter] C) Downside, in my perception * the summary needs to list all labels from the different tabs, to give enough context. So somewhat redoing of the whole dialog (depending amount of distinction from the parent style). * The summary only allows you to 'reset the inheritance'. If don't want to reset, but 'change' you still need to switch to the appropriate tab * You can only 'reset' to inherited from the general tab. Not while being inside the dedicated tab (so for example if you're inside the Font Tab) --- So what's done in the general tab is a kind of "Style inspector" in my perception, but different from the current one A) Instead of listing everything, it only list differences between the Parent Style B) It's interactive, being able to reset to "inheritance", instead of read-only (literally 'inspecting') Listing the difference between parent style and this style as a quick overview is surely useful, compared to having to walk through all tabs. OTOH, find it quite a UI clutter re-doing of having the whole dialog twice, except being differently formatted (and having limited functionality) --------- A totally different - wild idea - would be adding a 'style inspector', similar to the one in the sidebar. Which could be added at the right side of the current dialog. Similar to the TOC preview in Table of Content Dialog, including the hide/unhide checkbox. It would list the different between this Style and the Parent Style. Clicking on a entry navigates to the appropriated tab in the dialog Styles dialog. In which dialog you can 'reset' the style to inheritance. [currently not possible]. Say like attachment 166403 [details] (bug 88559 comment 21) This would avoid duplicating the dialog or settings, IMHO
From a user perspective, maybe we should prioritize delivering something to unset styles over the "perfect" solution? I think that with a simple solution we already help all the users who need this and then we can improve on that based on actual feedback and practical experiences.
I pushed a new version. the user is now presented the old Contains, with an Edit button. Clicking it you see the removable properties organized by tab. The Edit button becomes View, which permits you to go back to original view The property chips are now inside a scrollable area, in order to avoid overflow if you have many changes. I removed the vertical aligning of the properties. Unfortunatly the size of the remove bottom cannot be changed, I tried to make it smaller, without luck. I'm adding to screenshots, with the Edit button and with the View one
Created attachment 205532 [details] first view of changed properties from father style, edit button
Created attachment 205533 [details] after clicking the edit button, you can remove the properties individually
Remove button: the x is small, but the button is big, and it prevents a smaller line spacing inside a tab
(In reply to Paolo Benvenuto from comment #15) First of all - let me congratulate you for taking this on, doing the work and gradually polishing it into better form. Kudos! > I subdivided the changed properties by their tab because many properties > have cryptic words: for example, selecting a color in the area tab produces > the property "continous", which is impossible, without the organization by > tab, to understand what it refers to. Fair enough - as long as we don't overflow the dialog. > Let me try... The new attempt (attachment 205533 [details]) is better, but still has a few problems: * Some of the text seems overflow its own label area, so that we get ellipses. Example: "CTL Text: Noto Sans An..." * I see the same label twice: "CTL Text:" . * Instead of interleaving the properties of Western, CTL and Asian text, you should present all features of Western, then all of CTL, then all of Asian. That way, you would not need to write: "Asian foo: value", "Asian bar: value" but Just "Asian: foo: value bar: value". * Still _way_ to much vertical space between lines. * X'es still too small. * X'es must be much closer to the item they relate to than to the item next to it; right now there's a lot of space on each side. * In mahfiaz' original suggestion (attachment114176 [details]), X'es are raised and followed right after the property they relate to. I suggested you try that, and I still think it's a decent option. The small X'es which don't interrupt the flow of text too much are appealing. But - that is not the only approach, and if the approach is different then this recommendation is not valid; specifically, * With your current approach - a view mode vs an edit (or "delete properties" mode), there isn't as much of a motivation to maintain the flow of description text. In this case, it would be better to make the X's bigger, more prominent, and middle-aligned with properties. You have the alignment right, but they are much too small. Also, I would placing the X sing _right before_ rather than after the property which may be deleted > > * if possible, let change descriptions overflow to the next line rather than keeping them on the same line. > Explain better Suppose you have an item with a very long label, that starts near the end of the line. At the moment, you have to move it entirely to the next line, and waste a lot of the previous line. It would be nice, if it's possible, to start the label on the previous line and end it on the next. But... you know what? Never mind, that's probably too much trouble. Better to focus on reducing all of that space and packing things nice and tight.
(In reply to Schlomo Schapiro from comment #18) > I get it, and short of having a scroll bar appear on overflow I don't see a > solution. We should avoid scroll bars on dialogs if possible. Making the contents of a dialog movable breaks part of its metaphor, and makes the items on it look more like a document than UI widgets. We should make an effort not to get to that point. > Would a scroll bar be bad for those cases where there is an overflow? I > imagine that in >90% of all cases a style won't have so many settings to > need it. 10% is quite a lot. If it were 1%, then maybe; but even then I would expect something else. Perhaps a two-arrow-button page-flipping widget for style contents? At least it's not scrolling. And the more important thing is to make sure we cover the 99% of the cases without any scrolling. (In reply to Paolo Benvenuto from comment #24) > Unfortunatly the size of > the remove bottom cannot be changed, I tried to make it smaller, without > luck. (In reply to Paolo Benvenuto from comment #27) > Remove button: the x is small, but the button is big, and it prevents a > smaller line spacing inside a tab It has _got_ to be much much smaller (but with a larger X). If for some reason a button can't be made smaller - then make it not-a-button; or employ some 'dirty trick'. We could also ask for help with this (Heiko? Sahil? Caolan? Not sure who knows enough widget wizardry). Another alternative is dropping the X'es altogether. If you make the chips clearly visible, they can be 'buttons' themselves, and if you click them, they fall away. I am also not too fond of the "view" and "edit" buttons. A button with an alternating label seems like the wrong widget, especially since it's just sitting there all alone in the middle of the pane. It has to be some kind of two-state widget, I think... I might also think about something which could go on the side of the "Contains" . Or - maybe the whole area of the pane could be clickable, like a giant slab, switching between locked and unlocked state somehow. But this one is Just a thought.
Appreciate the effort a lot, and any solution is an improvement. Saying that, I don't like the Edit/View dichotomy. Don't we have plenty of space? The categories are surely beneficial in case of many modifications, and UI-wise the attributes should indent properly (could imagine a GtkTable with categories in the first column and attributes in the second; that would also simplify the code with that many new ui elements and bring scrolling capabilities out of the box). The approach has some flaws for accessibility, yet I don't see how to fix it. Thinking of an alternative workflow to remove attributes I could imagine the items as hyperlinks to the tabs/entries and some removal button there. To keep the UI simple it might be an icon per section / GtkFrame rather than every attribute. For instance at Indents & Spacing just Indents and not Before Text.
A viable alternative to the scrollbar / pages flipping problem could be adding a new tab dedicated to Style inheritance. That we we could use the full height of the dialogue and create a UI that works without switching modes. Maybe adding yet another tab is the least of all evils here? The tab could be called "Inheritance Editor" or "Inheritance" or "Summary" ...
(In reply to Heiko Tietze from comment #30) > Appreciate the effort a lot, and any solution is an improvement. Saying > that, I don't like the Edit/View dichotomy. Don't we have plenty of space? Actually, not that much. Example forthcoming. Just think about a style with all properties set to something > The categories are surely beneficial in case of many modifications, Disagree. I mean, I can live with them, but the more we make this presentation more like the regular UI of a dialog, the more we're duplicating the actual UI for viewing and modifying the style. This part is, so far, something that the user easily glosses over if they aren't particularly looking for it, and I would like it to stay that way. > Thinking of an alternative workflow to remove attributes I could imagine > the items as hyperlinks to the tabs/entries and some removal button there. That seems a bit contrived. I say: Let Paolo complete a straightforward implementation, which we all agree is a great improvement, then we can consider (and debate) potential alternatives, also from the accessibility perspective. I have some ideas (which I hinted at a few years back), but again, we should focus on the current implementation trajectory. > To keep the UI simple it might be an icon per section / GtkFrame rather than > every attribute. For instance at Indents & Spacing just Indents and not > Before Text. I'm not quite sure what you mean, but adding icons and hyperlinks makes the UI more complex.
Created attachment 205551 [details] Writer document with a property-rich style named 'dummy' For testing the layout of the new solution, use also the attached document, with a paragraph style named 'dummy'. That style has most properties accessible via the PS dialog set, and so its contents listing takes a lot of area, even as small text with no indentation and categorization. Screenshot to follow.
Created attachment 205552 [details] Screenshot of Writer 25.8 PS dialog with attachment 205551 [details] And now you see why we are actually quite short on space. The text barely fits the dialog, as it is.
So what about adding another tab for an Inheritance Editor?
(In reply to Eyal Rozenberg from comment #34) > And now you see why we are actually quite short on space. The typical scenario is different. Surely, we have to cover for anomalies. (In reply to Schlomo Schapiro from comment #35) > So what about adding another tab for an Inheritance Editor? I'm not thrilled by this idea. Draws too much attention to this feature and we end up with just the name and inheritance under General. But it's an option, yes.
I'm fixing the many-properties-situation paging the long list of modified properties. New version soon
Created attachment 205554 [details] dummy document in view mode
Created attachment 205555 [details] dummy document in edit mode
uploaded the new version, using closedoc.png for removing the property dummy document in view mode: https://bugs.documentfoundation.org/attachment.cgi?id=205554 in edit mode: https://bugs.documentfoundation.org/attachment.cgi?id=205555
I don't get why paging is superior to scrolling neither why we need as view vs. edit mode. The common scenario is a few changes compared to the parent - and we have to consider but not design for more content. My take: a simple scroll view always with label/button. But it works and I'm not blocking the work. Minor issue: long strings become abbreviated with end ellipsis. The removal button is hidden for these items. You could use ellipsis in the middle and ensure the button to be shown.
> Minor issue: long strings become abbreviated with end ellipsis. > The removal button is hidden for these items. Not in patchset 12.
> I don't get why paging is superior to scrolling It's not superior, perhaps it's more polite. I'm trying go remove the pagination if not needed. > neither why we need as view vs. edit mode With view and edit modes, the user doesn't see any change but the bottom button when opening the dialog; the feature for resetting the properties to parent's value is hidden behing the bottom button. If we accept that the user is presented with a change, view mode could be removed
(In reply to Paolo Benvenuto from comment #43) > I'm trying go remove the pagination if not needed. It's already removed if not needed
My comment is just one opinion. If I cannot convince people, in particular the one who implements the feature, it should not be followed :-).
How does code reviewing work? should I signal it to something?
(In reply to Paolo Benvenuto from comment #46) > How does code reviewing work? should I signal it to something? I checked the patch from UX/UI POV and made some comments. You could ask on IRC or the mailing list for reviewers. And if you don't find a reviewer but you are confident in the code, I would submit and let QA resp. the user test.
(In reply to Heiko Tietze from comment #41) > You could use ellipsis in the middle and ensure the button to be shown. Umm, no, I don't think that's legitimate. That is, the button must be shown, for sure; but the full text must also appear. IMNSHO.
Three decisions have to be taken: 1. In order to solve the problem of the big x button, do you think that we could make the properties 'buttons' themselves? so that, if you click them, they fall away. The tooltip, which has the complete property text (useful for the long ones, they are truncated and they carry ellipsis), would have the "click to remove this property", preceded by the property text only if it's too long 2. Should we remove pagination or not, replacing it with scrolling? from the point of view of usability, scrolling with the mouse wheel is easier than going with the mouse to the pagination button and clicking it. I'd prefer scrolling. 3. Should we remove the view/edit buttons and maintain only the "edit" view? the presence of the tab label makes more more more clear what the properties are; and both the code and the UI would be simpler. Please help me making this decision!
(In reply to Eyal Rozenberg from comment #48) > the button must be shown, > for sure; but the full text must also appear. IMNSHO. Apparently some property could be very long, and it's length could oversize the dialog, that's the reason why the truncation and the ellipsis. The full text of the property appears in the tooltip
(In reply to Paolo Benvenuto from comment #49) > Three decisions have to be taken: > > 1. In order to solve the problem of the big x button, do you think that we > could make the properties 'buttons' themselves? +1 > 2. Should we remove pagination or not, replacing it with scrolling? from the > point of view of usability, scrolling with the mouse wheel is easier than > going with the mouse to the pagination button and clicking it. I'd prefer > scrolling. +1 > 3. Should we remove the view/edit buttons and maintain only the "edit" view? > the presence of the tab label makes more more more clear what the properties > are; and both the code and the UI would be simpler. Only edit view if you ask me.
(In reply to Paolo Benvenuto from comment #49) Here are my 2 cents: > 1. In order to solve the problem of the big x button, do you think that we > could make the properties 'buttons' themselves? so that, if you click them, > they fall away. Would that not be surprising for users? I mean, clicking something typically doesn't remove it, just select it. And that's doubly true if we have an X mark for deletion. For now - I OPPOSE (but change my mind). > 2. Should we remove pagination or not, replacing it with scrolling? from the > point of view of usability, scrolling with the mouse wheel is easier than > going with the mouse to the pagination button and clicking it. I'd prefer > scrolling. NEUTRAL I don't like either of them, but I can live with any of them. At worst it would not look very elegant. What I will oppose is for us to need scrolling because we used to much spacing. In the latest screenshot, it looks like the edit mode takes 10x more space (especially vertical space) than the view mode. That is _not_ acceptable. 1.5x vertical space is already quite a lot if you ask me, I would expect no higher than that. Also, if view mode doesn't have categorization - we shouldn't have it in the edit mode. When I look at a property in view mode, then press edit - my eye should easily locate where it is in edit mode. > 3. Should we remove the view/edit buttons and maintain only the "edit" view? > the presence of the tab label makes more more more clear what the properties > are; and both the code and the UI would be simpler. I OPPOSE, for three reasons: The first is, that removing properties from the style should be something that happens infrequently and users should be 'protected' from the 'templation' of doing it. Just like you don't make it that easy to, say, delete an entire style. So, when a user opens the Style dialog and sees the General tab, they should not be met buy an enticing bunch of X marks. The second is space. Unless you switch to a design in which fits the dummy style all onto the dialog, in edit mode, with X marks and all - the edit mode is bloated and doesn't give you the full view. And the third and less-significant reason is the fact that I would like to be able to copy the 'Contains' text sometimes, and will likely not be able to do so in edit mode.
(In reply to Eyal Rozenberg from comment #52) > > 1. In order to solve the problem of the big x button, do you think that we > > could make the properties 'buttons' themselves? so that, if you click them, > > they fall away. > > Would that not be surprising for users? I mean, clicking something typically > doesn't remove it, just select it. And that's doubly true if we have an X > mark for deletion. > > For now - I OPPOSE (but change my mind). You're right: it would be surprising for users. But the main reason for doing that is the big x button, no way to reduce it's height, and then a lot of vertical space used. Finding a way to make a small button would resolve this dilemma. > > 3. Should we remove the view/edit buttons and maintain only the "edit" view? > > the presence of the tab label makes more more more clear what the properties > > are; and both the code and the UI would be simpler. > > I OPPOSE, for three reasons: > > The first is, that removing properties from the style should be something > that happens infrequently and users should be 'protected' from the > 'templation' of doing it. Just like you don't make it that easy to, say, > delete an entire style. So, when a user opens the Style dialog and sees the > General tab, they should not be met buy an enticing bunch of X marks. Maybe, instead of the view/edit pair, a button which activates the remove feature? "Permit removing", e.g. > The second is space. Unless you switch to a design in which fits the dummy > style all onto the dialog, in edit mode, with X marks and all - the edit > mode is bloated and doesn't give you the full view. Well, in view mode it's very difficult to understand the properties. For the space argument, see point 1 > And the third and less-significant reason is the fact that I would like to > be able to copy the 'Contains' text sometimes, and will likely not be able > to do so in edit mode. The Contains text isn't copyable.
Created attachment 205664 [details] Screencast (In reply to Eyal Rozenberg from comment #52) > > 1. In order to solve the problem of the big x button, do you think that we > > could make the properties 'buttons' themselves? so that, if you click them, > > they fall away. > > Would that not be surprising for users? I mean, clicking something typically > doesn't remove it, just select it. And that's doubly true if we have an X > mark for deletion. Would it improve if would act some kind of 'tag' where a 'X' appears on mouse over?
(In reply to Telesto from comment #54) > Created attachment 205664 [details] > Screencast > > (In reply to Eyal Rozenberg from comment #52) > > > 1. In order to solve the problem of the big x button, do you think that we > > > could make the properties 'buttons' themselves? so that, if you click them, > > > they fall away. > Would it improve if would act some kind of 'tag' where a 'X' appears on > mouse over? +1
(In reply to Telesto from comment #54) > Created attachment 205664 [details] > Screencast > > Would it improve if would act some kind of 'tag' where a 'X' appears on > mouse over? apparently weld framework should be bypassed, I don't know if it's permitted to do it. Weld ensures cross platform working, if I'm right.
(In reply to Paolo Benvenuto from comment #53) > Well, in view mode it's very difficult to understand the properties. * I'd say it's more difficult to understand in _edit_ mode. With edit mode, I see a bunch of pieces of text scattered around the dialog pane, with some of them missing some of the text because of ellipsis, and in fact, I don't even see most of the properties since they're off-screen. Super-hard to understand. * Now, it's true that it _would_ be easier to understand if view mode had, say, clearer separators between categories; like the category/tab name in boldface. Would take a bit more space, but it would be worth it. * And I'll also concede that being used to 'Contains' descriptions makes it easier for me. For those who lack that experience, and who look at 'Contains' for the first time - we have actual dialog tabs that let you see exactly what the style's properties are. * There are exceptions: Numbers with no description, like " + 6 + ". But that's just a bug if you ask me. > You're right: it would be surprising for users. But the main reason for > doing that is the big x button, no way to reduce it's height, and then a lot > of vertical space used. > > Finding a way to make a small button would resolve this dilemma. * I can't believe the button needs to be that big to get an X that's not so big. Surely there's a way to paint the buttom with no padding or something. * Even when the x's were small, there was still _way_ too much space. Vertical and horizontal. * You could perhaps make the X buttons 'float' somehow, e.g. have a different Z-index or whatever. > The Contains text isn't copyable. That's bug 170770, which I am hoping will get fixed :-P > Maybe, instead of the view/edit pair, a button which activates the remove > feature? "Permit removing", That's essentially the same as two modes. It would be essentially a lock/unlock toggle. So you're just suggesting replacing the button with a toggle, I'm fine with that. (In reply to Telesto from comment #54) > > Would that not be surprising for users? I mean, clicking something typically > > doesn't remove it, just select it. And that's doubly true if we have an X > > mark for deletion. > > Would it improve if would act some kind of 'tag' where a 'X' appears on > mouse over? Well, * The hover graphic would need to make it clear that the click action means deletion. * This would introduce a new kind of widget, which AFAIK we don't have right now. * It would be problematic if view and edit mode were unified.
(In reply to Eyal Rozenberg from comment #57) > * I can't believe the button needs to be that big to get an X that's not so > big. Surely there's a way to paint the buttom with no padding or something. Apparently there isn't any. I've tried all the ways, Weld always adds a big padding.
(In reply to Paolo Benvenuto from comment #58) > Apparently there isn't any. I've tried all the ways, Weld always adds a big > padding. I don't suppose we can do something that isn't "weld"? Anyway, if that's the case, then: * Let's file a bug about that and ask some VCL wizards to fix it. * Personally, I'd take the delete-on-click, tight packing of properties, and no X's whatsoever, over X's, no-delete-on-click and too much space. But others may have a different opinion of course.
New patch, I reverted to scrolling in edit mode. Some properties appeared as they belong to another tab: FIXED. The sorting of the properties was extemporary inside a tab: FIXED, now the properties are shown in a fixed order. Some properties can get very very long (e.g. in borders tab), the chip is truncaded with ellipses, full text visible in the tooltip.
Created attachment 205733 [details] General tab in edit mode, patchset 13
(In reply to Eyal Rozenberg from comment #59) > * Personally, I'd take the delete-on-click, tight packing of properties, and > no X's whatsoever, over X's, no-delete-on-click and too much space. But > others may have a different opinion of course. I suppose that the line spacing in edit mode is determined by the button. If the chips converts into a button, the same line spacing appears.
(In reply to Paolo Benvenuto from comment #49) > 1. ...make the properties 'buttons' themselves? -0.5 (but this show "x" on hover idea is tempting) > 2. remove pagination +1 (KISS; paging is common on browsers but not desktop) > 3. remove the view/edit buttons +1 (even more if #1 is implemented)
(In reply to Paolo Benvenuto from comment #62) I'll first say that even if implementation stops at this point - it looks... tolerable, I guess. I don't like it but I can live with it. And the fact that it works is very useful. So, again, thanks :-) > I suppose that the line spacing in edit mode is determined by the button. If > the chips converts into a button, the same line spacing appears. Basically, chips are widgets we don't currently have (right?). But - maybe we (and by that I mean you...) can make chips out of labels instead of buttons. Don't labels have click events we could capture?
problem with big remove button resolved, uploaded the new patchset to gerrit!
The latest patchset had a problem: the properties were not removed if removed in the General tab with the property remove button and then closing the dialog with Ok. Fixed in patchset 22, which adds a writer test. Besides that, the new patchset remove completely the ellipsis, all the properties are show full text, without truncanting them if too large. I think it's a good work! :-)
Created attachment 205806 [details] Style dialog in writer
Created attachment 205807 [details] style dialog in calc The patch works in both writer and calc
Paolo Benvenuto committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/52010fde0917051e043674c8da42d9a06340b571 tdf#89826 Add interactive property chips to style Organizer tab It will be available in 26.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Paolo Benvenuto committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/de9fb540060af5df629c9c07e21445f4d97fcd71 tdf#89826: remove unused GetWhichToTabOverrides() It will be available in 26.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
A calc test was uploaded: https://gerrit.libreoffice.org/c/core/+/200887
Paolo Benvenuto committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/467af6b5443bd09221e359db4b98e1999e7a8ab9 tdf#89826 Translate Italian code comments to English in tabdlg.cxx It will be available in 26.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I tested the daily build and it looks great!!! Thanks a lot!!! Exactly as I imagined it and 100% super useful and valuable!
Paolo: feel free to close as fixed.