-
Notifications
You must be signed in to change notification settings - Fork 11
feat: Enhanced UI and Functionality for the Select Screen #18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Reviewer's Guide by SourceryThis pull request introduces a new display selection screen with enhanced UI and functionality. It includes display cards with preview images and technical specifications, filter chips for display types, a DisplayProvider for data management, and a DisplayModel class to represent display specifications. The changes also involve adding a JSON file for display configurations and updating the main application to include the new screen. No diagrams generated as the changes look simple and do not need a visual representation. File-Level Changes
Assessment against linked issues
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @Vishveshwara - I've reviewed your changes - here's some feedback:
Overall Comments:
- Consider using a consistent naming convention (e.g., camelCase) for model properties like
ModelName
. - The
_getEpdForClassName
method inDisplayProvider
could be refactored to use a map for better readability and maintainability.
Here's what I looked at during the review
- 🟢 General issues: all looks good
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Thanks, please follow the colors same as in the badge magic app https://github.com/fossasia/badgemagic-app. Use white as a background color for example. |
Thank you for your feedback, please review the updated colors below: |
@mariobehling We might want to review the logic used here. This doesn't align with the structure developed by @kienvo. |
@AsCress |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Vishveshwara Understand the fact that using an LLM to generate code isn't bad. However, if you do so, the code has to be cleaned properly before you commit it. LLM code contains numerous things which are either irrelevant / not needed. The right approach is to always get an understanding of where we are, what functionality we want to achieve and then decide upon an approach for the same which takes into account the exact requirements and constraints of the project, something which an LLM has no idea about.
@@ -0,0 +1,26 @@ | |||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would be actually needing JSON storage for this ? The number of displays that we have to interact with are very limited and we already have an abstract class Epd
, which is extended to model a display. Those classes could simply be modified to add whatever more parameters you want to show about the displays.
"colors": ["black", "white", "red"], | ||
"driver": "UC8253", | ||
"imagePath": "assets/images/displays/epaper_3.7_bwr.png", | ||
"epdClass": "Gdey037z03" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, how is this approach scalable, when we are anyways creating a new class for any new display that we want to add ?
|
||
//Colors used in the app | ||
// Primary Colors | ||
const Color colorPrimary = Color(0xFFD32F2F); // You can adjust this color value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove any such LLM comments before committing code.
If you do want to add comments to your code, add proper documentation comments for every function you add, so that it could also be used to generate documentation.
|
||
void main() { | ||
runApp(MultiProvider(providers: [ | ||
ChangeNotifierProvider(create: (context) => ImageLoader()), | ||
ChangeNotifierProvider(create: (context) => DisplayProvider()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DisplayProvider()
is something which we are using to manage and select displays only. There's no need to register it as a ChangeNotifierProvider()
in main()
for the whole app.
} | ||
|
||
// Helper method to find GCD for aspect ratio calculation | ||
int _findGCD(int a, int b) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why a separate function for GCD
? Core dart libraries can be used for this purpose.
import 'package:magic_epaper_app/util/epd/edp.dart'; | ||
|
||
class DisplayModel { | ||
final String id; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having so many parameters for each display (id
, name
, ModelName
) doesn't make sense to me. This just increases complexity.
} | ||
|
||
// Helper method to get the appropriate EPD based on class name | ||
dynamic _getEpdForClassName(String className) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another function which just increases complexity, if you're aiming for a scalable approach.
// Notify listeners that the data has changed | ||
notifyListeners(); | ||
} catch (e) { | ||
print('Error loading displays from JSON: $e'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avoid having print()
in your code. Use a logging library instead.
class DisplayCard extends StatelessWidget { | ||
final DisplayModel display; | ||
final bool isSelected; | ||
final VoidCallback onTap; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just simply wrap DisplayCard
in a GestureDetector
, wherever used (in display_selection_screen.dart
).
const ColorDot({ | ||
super.key, | ||
required this.color, | ||
this.selected = false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you use selected
anywhere ? Should only add parameters whenever needed.
@AsCress this is the reference app, which was mentioned in the ideas list, which supports multiple displays. |
@Vishveshwara, your proposed UI looks good. The thing is, the Epd class was there. You just have to improve it instead of relying on LLM. You could use it as a base, resolve the reviews, then we'll have a nicer app. To resolve the reviews, add incremental commits to this branch, or commit with |
Fixes #17
Changes:
Added new DisplaySelectionScreen with grid layout for display selection
Created display cards with:
Implemented filter chips for All/Color/B&W/HD displays
Created DisplayModel class with:
Created DisplayProvider for:
Added displays.json with display configurations for easy support for more displays.
Screenshot:

Summary by Sourcery
Implement a comprehensive display selection screen with advanced filtering and display information features for the ePaper application
New Features:
Enhancements:
Chores: