In D19473#423221, @davidedmundson wrote:Lets say I have a window
"D19473 Present Windows Effect: Allow imprecise match on filtering windows - Mozilla Firefox"And search for "telegram", I'm going to get all the way to "telegr" before the test fails.
(d19473 presenT windows Effect: aLlow imprEcise match on filterinG windows - mozilla fiRefox)It's hindering the original goal of making things faster to search.
I fear it's going to appear broken to the end user who can't see why it's showing these false positives, even if this is an option.
- Queries
- All Stories
- Search
- Advanced Search
Feed Advanced Search
Advanced Search
Advanced Search
Mar 4 2019
Mar 4 2019
leandrosantiago added a comment to D19473: Present Windows Effect: Allow imprecise match on filtering windows.
Mar 3 2019
Mar 3 2019
leandrosantiago added a comment to D19474: Present Windows effect: remove label 'Filter' when filtering windows.
In D19474#423219, @davidedmundson wrote:I'd rather my product was easily used and ugly than beautiful and unclear.
I think it does need something to indicate what's happening if you randomly press a key.
A small search icon to the left of the text might suffice.
Mar 2 2019
Mar 2 2019
Aug 18 2018
Aug 18 2018
leandrosantiago added inline comments to D14891: fix potentially bug on accessing global variable on instance of AtCore.
leandrosantiago updated the diff for D14891: fix potentially bug on accessing global variable on instance of AtCore.
Make type explicit on enum -> string conversion
Aug 17 2018
Aug 17 2018
leandrosantiago added inline comments to D14891: fix potentially bug on accessing global variable on instance of AtCore.
leandrosantiago updated the diff for D14891: fix potentially bug on accessing global variable on instance of AtCore.
Use QtMetaEnum to generate the string from the axis.
leandrosantiago abandoned D14906: Fix potentially bug on accessing global variable on instance of AtCore.
Revision created by mistake.
leandrosantiago added a comment to D14891: fix potentially bug on accessing global variable on instance of AtCore.
In D14891#310391, @rizzitello wrote:It seams that the user would need to be calling this function at the same time on more then one instance. How likely is that to happen? How do you feel about the code below? It removes the need for that variable all together. and removes the default case that will never be called.
Just imagine someone (like that eccentric rich cousin that everyone has :-)) using atcore to implement a client that is able to print to several printers at the same time. In order to AtCore to be used as a library, it needs to make no (or at least as few as possible) assumptions about how it is used (or at least document that it should not be used to control multiple printers).
void AtCore::move(AtCore::AXES axis, int arg) { switch (axis) { case AtCore::X: move(QLatin1Char('X'), arg); break; case AtCore::Y: move(QLatin1Char('Y'), arg); break; case AtCore::Z: move(QLatin1Char('Z'), arg); break; case AtCore::E: move(QLatin1Char('E'), arg); break; }; }
Aug 16 2018
Aug 16 2018
Jul 22 2018
Jul 22 2018
Jul 2 2018
Jul 2 2018
leandrosantiago updated the summary of D13859: Hide private implementation classes in order to prevent symbol collision.
Sep 3 2016
Sep 3 2016
Please use leandrosansilva@gmail.com
@dhaumann, no, I don't have commit rights. Please commit it for me.
Sep 2 2016
Sep 2 2016
leandrosantiago retitled D2643: Fix constant crashes related to the vi command bar from to Fix constant crashes related to the vi command bar.